56 Объектно-ориентированное программирование. Абстрагирование. Инкапсуляция, наследование, полиморфизм.

Под объектом (Object) понимается осязаемый или видимый предмет. Также объектом может быть нечто, воспринимаемое мышлением (например, облако инертного газа), или то, и что направлена мысль или действие. Итак, объект — это опознаваемый предмет, блок или сущность (реальная или абстрактная), имеющие важное функциональное значение в определенной области. Объект обладает состоянием, поведением и индивидуальностью. Состояние (State) объекта характеризуется перечнем всех возможных (обычно статических) его свойств (Property) и их текущими значениями (обычно динамическими, т.е. изменяющимися во времени). Поведение. Объекты не существуют изолированно друг от друга. Между ними идет передача сообщ ний. Состояния этих объектов могут изменяться. Поэтому очень важно взаимодейств] объектов в процессе их функционирования. Поведение характеризует то, как один объе воздействует на другие объекты или как он подвергается их воздействию в постоянно м няющихся условиях. У людей разного возраста это понятие ассоциируется с очень разными представления!. Ребенок, услышав слово «класс», сразу подумает о школе. Человек, изучавший когда-«Диалектический материализм», возможно, с содроганием вспомнит о революционн борьбе. Не пугайтесь. В нашем случае вы избавлены от неприятных ассоциаций. В« в программировании в общий класс (Class) просто объединяются объекты, близкие по си ей структуре и поведению, хотя каждый из них может отличаться от других объектов это класса своим поведением и состоянием. Итак, каждый объект - это представитель (экзем ляр) класса. Поэтому термины экземпляр класса и объект являются взаимозаменяемы!* Синонимом понятия класс является также понятие тип (Туре). ООП – это методология, основанная на представлении программы в виде совокупности объектов, каждый из которых является реализацией собственного класса, которые в свою очередь образуют иерархию на принципах наследования. Иерархия – это ранжирование или упорядоченная система абстракций. Иерархические системы обычно состоят из нескольких подсистем, причет то, что на одном уровне абстракция является элементом системы, на более низком уровне является системой. Инкапсуляция. Предпологает защиту данных и методов обьекта с целью предотвращения доступа к ним конечных пользователей самого обькета. Для осущ защиты данных и методов обьекта исп-ся директивы: Private приватные данные и методы Protected – защищенные д и м Public – общедоступные д и м Данные и методы помещенные в раздел privatee могут испся только в пределах модуля, в котором описывается данных обьект. Программа или другой модуль исп-я данный модуль не могут испть приватные данные и методы.. приватные данные и методы применяются в других методах данного обьекта которые могут быть доступны конечному юзеру, но составляют внутреннюю закрытую часть обьекта. Защищенные данные и методы примся для частного их сокрытия, доступными они становятся только для других оьектов создаваемых конечным юзером на базе исходного обьекта путем наследования. (вот дА! Дура я такая пишу обьекта с мягким знаком. Можете смеяться!!! Ха ха ха) общедоступные данные и методы составляют внешний интерфейс обьекта они доступны для любого конечного юзера исп-го данный обьект. Наследование. Наз передача данных и методов созданного обьекта вновь создаваемому обьекту. Помимо унаследованных данных обьект наследник может вводить новые данные и методы и может переопределять унаследованные методы. Для обьектов наследников можно использовать сокрытие методов и данных. Наследник может испть в составе своих методов методы предка обьявленные под дерективой public и protected. Доступа к методам у предка под дерективой private наследник не имеет если он размещается в другом методе. Испе наследования позволяет значит сократить трудозатраты на разработку прог обесп за счет исп-я автовключ в обьект наследник методы и данные от родителя. От того как будет организована структура обьекта родитея будет зависеть возможность его наследования. Поэтому любой обьект не должен писаться сам для себя, а должен предусматривать возможность его наследования . наследование может продолжаться неограниченно. тогда создаются иерархии обьектов. Полиморфизм. Это обеспечение корректности вызовов методов принадлежащих указанным экземплярам обьектов.

Type objA=object

Procedure M1;

Procedure M2;

End;

Procedure ObjA.M1;

Begin…

M2

End;

Наследник наследует обьект А

Type ObjB=object(ObjA);

Procedure M2;

End

Procedure ObjA.M2;

Begin

Writeln(‘this is object A’);

End;

Procedure ObjB.M2;

Begin

Writeln(‘Yhis is object B’);

End;

……..

var A:objA;

B: ObjB;

Begin

…

B.M.;

End;

В р-те вызова М1 будет выведена фраза это обьект А, в примере испся ранее связывание обьектов при котором ссылки на вызываемые методы устанавливаются на стадии компиляции проги. Для того чтобы вызывался корректный метод М2 обьекта В необходимо испть не раннее а поздние связывания при к-ом пердача управления вызываемым методом осущ не на стадии компиляции а на стадии выполнения программы. Позднее связывание Реализуется посредством виртуальных методов для которых создается спец таблица виртуальных методов в к-е заноситься информация о типе вызываемого обьекта и поиск нужного метода производиться путем обращения к этой таблице. Если мы сделаем виртуальные методы вызываемыми т.е сделаем позднее связываение то при вызове метода В .Ь1 должен вызываться метод Ь2 обьекта В. Type ObjA=Object; Для реализации вирт механизма вводиться особый метод задачей которого явл создание таблицы вирт методов этот метод конструктор Constructor init; И всегда должен вызываться первым в состав действия по инифиализации обьекта. Методы вкл в эту таблицу должны иметь директиву виртуал procedure M1; virtual Это правило и для наследников выполняется как обычные методы. Статистические методы раннего связываения всегда работают быстрее чем виртуальные т.к. в вирт-х методах осущ доп операция обращения в таблице вирт методов. Эти методы внутри обькта надо сочетать. Абстрагирование. Один из главных способов решения сложных задач. 4 вида абстракции: 1 аб-я сущности обьекта 2 аб-я поведения обьекта 3 аб-я в виде виртуальных машин 4 аб-я произвольная в первом и втором виде абстракция представляет собой описание самого обьекта и его поведения ( операции которые он может выполнять и которые могут выполняться над ним) в различ языках прогр-я операции наз по разному: операция, метод , функция элемент. Полный набор операций которые обьект может осуш над другим обьектом наз протоколом. Абстракция – это операция выделения наиболее важных компонентов (составляющих) обьекта с точки зрения того кто производит этот процесс. На основании наиболее важных компонентов строиться идеализированная модель обьекта, отражающая процесс абстракции. Класс – множество обьектов связанных обьщностью структуры и поведения. Объектно-ориентированное программирование. В настоящее время наиболее привлекательные для программистов языки базируются на так называемой объектной модели, которая имеет четыре главных элемента: абстрагирование, инкапсуляция, модульность, иерархия. Абстрагирование — выделения абстракций (abstraction), под которыми понимаются существенные характеристики объекта, которые отличают его от всех других объектов и четко определяют его концептуальные границы для наблюдателя. Инкапсуляция (encapsulation) — разделение элементов абстракции, которые образуют ее структуру и поведение Модульность (modularity) — разделение системы на модули (module), под которыми понимаются единицы кода, служащие блоками физической структуры системы. Иерархия (hierarchy) — подчинение или упорядочение абстракций. Две типичных иерархии в сложной системе — иерархия наследования «общее/частное», присущая, обычно, типам (классам) и иерархия агрегирования «целое/часть», присущая, обычно, элементам (объектам). Иерархия присуща также модулям и другим частям системы. Наиболее явно эти черты присутствую в языках, реализующих концепции объектно-ориентированного программирования. Под последним понимается методология реализации, при которой программа организуется как совокупность сотрудничающих объектов, каждый из которых является экземпляром какого-либо класса, а классы образуют иерархию наследования. При этом классы обычно статичны, а объекты очень динамичны, что поощряется динамическим связыванием и полиморфизмом. Для ООП характерны понятия наследования и полиморфизма. Наследование (inheritance) — отношение между классами, при котором класс использует структуру или поведение другого (одиночное наследование) или других (множественное наследование). Наследование вводит иерархию «общее/частное». Полиморфизм (polymorphism) — положение теории типов, согласно которому имена (например, переменных) могут обозначать объекты разных (но имеющих общего родителя) классов. Следовательно, любой объект (метод), обозначаемым полиморфным именем, может по-своему реагировать на некий общий набор операций (аргументов).

57 - Критерии качества программного обеспечения

Программное обеспечение как товар. Создание программного обеспечения для персональных компьютеров за какой-то десяток лет превратилось из занятия программистов-одиночек в важную и мощную сферу промышленности. Только в США более 50 фирм – производителей программного обеспечения имеют объемы продаж более 10 млн. дол., а у десяти из них (в частности, Microsoft, Lotus, Novell, Borland, Autodesk, Symantec и Computer Associates) объемы продаж превышают 100 млн. дол. Поэтому развитие программного обеспечения, предназначенного для широкого круга пользователей, происходит уже не в состязании индивидуальных программистов, а в процессе ожесточенной конкурентной борьбы между фирмами-производителями программного обеспечения. Доля некоммерческого программного обеспечения постоянно снижается и все более ограничивается программами, создаваемыми в процессе научных исследований или для собственного удовольствия. Важнейшие свойства программ. При разработке коммерческих программ основной задачей фирм-разработчиков является, естественно, обеспечение их успеха на рынке. Для этого необходимо, чтобы программы обладали следующими качествами: функциональность программы, т.е. полнота удовлетворения ею потребностей пользователя; наглядный, удобный, интуитивно понятный и привычный пользователю интерфейс (т.е. способ взаимодействия программы с пользователем); простота освоения программы даже начинающими пользователями, для чего используются информативные подсказки, встроенные справочники и подробная документация; надежность программы, т.е. устойчивость ее к ошибкам пользователя, отказам оборудования и т.д., и разумные ее действия в этих ситуациях. Стандартизация. Во многих областях совместная работа различных производителей программного обеспечения приводит к стандартизации отдельных элементов интерфейса программ, форматов данных и т.д., что весьма удобно для пользователей. Это происходит прежде всего потому, что разработчики программ перенимают друг у друга удачные находки и приемы и стремятся обеспечить совместимость с другими наиболее популярными программами. В результате использования ниспадающих (pull-down) меню или вид таблицы табличного процессора будут приблизительно одинаковыми во всех программах, хотя они созданы различными разработчиками, подобно тому, как похожи кнопки в лифтах, изготовленных разными заводами. Удобство пользовательского интерфейса программ является важнейшим фактором, определяющим приемлемость программы для пользователей, а значит, и ее успеха на рынке. Большинство выпускаемых на рынок программ используют достаточно стандартные методы организации интерфейса: ниспадающее меню, панели для выбора ответа, встроенные диалоговые справочники и т.д. Как правило, пользователь может работать не только с клавиатурой, но и с мышью. В последнее время все большее количество программ используют графический пользовательский интерфейс (graphical user interface, GUI), в котором, в частности, для упрощения работы пользователя вместо надписей на экране употребляются рисунки (пиктограммы). При этом графический интерфейс используется не только в таких программах, как графические редакторы или издательские системы, но и в табличных процессорах, текстовых редакторах и т.д. Многие из программ с графическим интерфейсом работают под управлением системы Windows. Увеличение мощности программ. Важнейшей тенденцией развития программного обеспечения является неуклонное увеличение их мощности – программы могут обрабатывать большие количества данных, делать это быстрее, предоставляют пользователю больше выполняемых функций и т.д. Таким образом, разработчики программного обеспечения используют возможности, появляющиеся из-за увеличения мощности компьютеров. Весьма заметно и стремление к интеграции функций программного обеспечения. Например, в табличный процессор включаются функции базы данных, в издательскую систему – функции текстового редактора и т.д. Оборотной стороной увеличения мощности программ является повышение их требований к аппаратуре. Коммерческие разновидности программ. В настоящее время большинство программ распространяется на коммерческой основе. Для приобретения таких программ необходимо вначале заплатить за них определенную сумму денег. Такие программы называются коммерческими. Существуют и такие программы, которые распространяются бесплатно. Чаще всего эти программы написаны каким-нибудь опытным программистом для себя, затем переданы для общего пользования. Такие программы называются бесплатными (freeware). Иногда разработчики программы указывают, что их программа является бесплатной для индивидуальных пользователей, но для использования в организациях должна покупаться соответствующая лицензия. Промежуточное положение между бесплатными и коммерческими программами занимают условно-бесплатные программы (shareware). Эти программы можно получить и опробовать бесплатно, но для систематического их использования необходимо уплатить разработчикам или распространителям программы определенную сумму. Качество произведенного программного продукта, как и для всякого производства, является важным технологическим понятием: достижение приемлемого качества должно планироваться, а в процессе технологического цикла разработки качество должно быть предметом инспекций и контроля. Классически исходное представление о качестве связано с тем, что разработанный продукт подтверждает свою спецификацию, при этом спецификация должна быть ориентирована на характеристики, которые желает получить клиент [1 P. Crosby. Quality is Free/McGraw-Hill, N.Y., 1979.]. В работе [2 P. Nesi. Objective Quality, 1995//Objective Software Quality, LNCS № 926, Springer, 1995, p. 1-9.] отмечается, что иная, не менее, широкая трактовка понятия качества может быть выражена утверждением "пригодность для цели". Так или иначе, понятие качества программного обеспечения – это прежде всего внешняя оценка. Степень качества связана с удовлетворением потребностей пользователя. Современные технологические стандарты и учебники по технологии программирования уточняют понятие качества, вводя совокупность аспектов, в свете которых и должно рассматриваться качество. В работе [3 I. Sommerville. Software Engineering/Addison-Wesley Pub. Co., 1996], например, в роли таких аспектов выступают: безопасность, защищенность, надежность, устойчивость, понимаемость, тестируемость, адаптируемость, модульность, сложность, переносимость, доступность пользователю, повторная используемость, эффективность, изучаемость и сопровождаемость. Этот список достаточно полон и, по-видимому, включает все интересные для рассмотрения аспекты качества. Похожий перечень приводится и в монографии российского автора [4 В. Липаев. Качество программного обеспечения//Финансы и статистика, М., 1983.], однако с учетом того, что за десяток лет, разделяющий эти работы, понятие качества программного обеспечения претерпело определенную эволюцию. С другой стороны, все или по крайней мере большинство из перечисленных аспектов качества определенным образом связано с некоторыми свойствами компонентов программной системы, а также со свойствами структуры программного обеспечения как системы компонентов. Негласно существует программистский "гамбургский счет" оценки качества программной реализации. Кстати, знакомство с исходными текстами ряда весьма уважаемых и широко используемых программных продуктов показывает, что по этому "гамбургскому счету" они выглядят не очень хорошо. Действительно, разумная организация потока управления и информационных потоков в реализованной программе заведомо улучшает такие аспекты, как устойчивость, понимаемость, тестируемость, адаптируемость, переносимость, повторная используемость, сопровождаемость, да, возможно, и другие. Для оценки внутренних достоинств реализации программы с технической стороны в работе [5 И. Поттосин. "Хорошая программа": попытка точного определения понятия//Программирование.-1997. - № 2. - С.3-17.] было предложено понятие добротности программы (в английском переводе [6 .V. Pottosin. A "Good Program": An Attempt at an Exact Definition of the Term.//Programming and Computer Software. - v. 23, № 2. - 1997. - p.59-69] приведен соответствующий англоязычный термин "soundness"). В термин "добротность" вкладывается такой аспект хорошей программы, который заключается в том, что программа разумно, рационально реализована, с достаточно продуманной организацией потоков управления и информационных потоков, не слишком переусложнена. Выбором этого термина подчеркивается чисто техническая сторона оценки – важна отнюдь не красота или изящество программы, которые, как правило, являются следствием оригинальной и интеллектуально сильной идеи, реализованной в программе, а именно качество собственно реализации, ее профессионализм, продуманность, что и соответствует русскому слову "добротность". При такой оценке "за бортом" остаются многие аспекты качества ПО, прежде всего касающиеся функционального соответствия программного продукта запросам клиента. Однако вместе с тем, как уже и отмечалось, хорошая оценка этой внутренней характеристики программ, составляющих программный продукт, дает определенную уверенность, что другие важные характеристики качества программного обеспечения тоже будут выглядеть неплохо. Достоинством такого технического подхода к оценке качества программ является возможность предложить достаточно точные методы или дисциплины оценки добротности программ при инспекции и контроле качества ПО на этапе кодирования, иначе говоря – на этапе создания собственно программного текста. Недостаток этого подхода в том, что чаще всего можно говорить о добротности компонентов, но не о добротности всей программной системы в целом. Само понятие добротности нуждается в уточнении, что и будет сделано при описании критериев добротности. Критерии добротности программ. Определив добротность программ как разумную, рациональную, непереусложненную организацию информационных потоков управления в программе и разумное построение вычислений, мы не избавились от множественности критериев оценки этой добротности. Содержание понятия добротности допускает разные классы оценок. Пытаясь оценить различные критерии добротности программ, можно свести их к следующим классам. Количественные критерии. Количественные критерии добротности программ, как правило, в отличие от всех последующих классов критериев, относительны – они не отвечают на вопрос о том, добротна ли данная программа, а позволяют сравнивать близкие программы и на основании сравнения определять, какая программа добротнее. Примерами таких оценок, составляющих основу количественных критериев, являются: мера "совершенства" Холстеда, оценка сложности управляющего графа программы, выражаемая цикломатическим числом; различные оценки сложности программных систем и компонентов в них и т.п. Достоинство количественных критериев в том, что с их помощью можно оценивать добротность как компонентов, так и самих систем. При модификации программы или системы можно оценивать, не изменилась ли заметно их сложность, не нарушена ли добротность. Итак, с точки зрения количественных критериев добротная программа – это не переусложненная программа, а программа приемлемой степени сложности. Генетические критерии. Известен следующий практический подход к оценке качества программ: программа признается хорошей, если она произведена по технологии, вызывающей доверие. Класс критериев, основанный на таком подходе – оценке добротности программ, так сказать, "по происхождению", мы назвали (может быть, не очень удачно) генетическим. Действительно, всякая "хорошая" технология программирования предполагает хорошо продуманную дисциплину разработки, надежно переходящую от спецификации продукта к его реализации. Поскольку при такой дисциплине гарантируется – в достаточной степени – соответствие реализованной программы ее спецификации, то, привлекая широкое понятие качества ПО, качество продукта должно быть довольно высоким – лишь бы спецификация была полной и адекватной нуждам пользователя. Для добротности интересно то, что продуманная дисциплина перехода от спецификации к программному тексту должна давать хорошую его организованность, разумную реализацию в нем потоков управления и информационных потоков. Итак, с точки зрения генетических критериев можно быть уверенным в добротности программы или системы, если они произведены по технологии, признаваемой хорошей. Структурные критерии. Разумная организация потока управления предполагает его ясное синтаксическое отображение в программном тексте. Подход к такому отображению сформулирован давно и выражается понятием структурированной программы. В такой программе управление представлено в виде иерархии регулярных управляющих структур, каждая из которых имеет один вход и один выход. Помимо такого простого требования, исключающего хаотичное переплетение потоков управления ("спагетти"), для добротной программы с регулярностью управления важно иметь хорошо продуманную процедурную основу (или, для объектно-ориентированного случая – систему классов). Все подобные требования к добротности программ мы относим к структурным критериям. Ясная и четко выраженная структура управления, требуемая структурными критериями, легко сопоставляется с внешними аспектами качества программного обеспечения. Недаром большая часть известной заметки [9 E.Dijkstra. Go to Statement Considerеd Harmful//Commun. ACM. - 1968. - V. 11, № 3, - p.147-148], положившей основу структурному программированию, посвящена тому, что в структурированных программах текст легко сопоставить с множеством отображенных в нем вычислительных процессов, иначе говоря, структурированные программы резко повышают понимаемость, а значит, и ряд других аспектов качества. Если оценка процедурной основы или системы классов требует нетривиальных умозаключений (частично поддерживаемых некоторыми вычисляемыми мерами сложности), то структурированность программы легко усматривается из программного текста, и ее мы считаем неотъемлемым свойством добротных программ. Итак, структурные критерии диктуют нам, что добротной признается структурированная программа с разумной организацией процедурной основы и/или системы классов. Прагматические критерии. В работе [5] вводится и определяется специальный класс критериев добротности программ, названный прагматическими критериями. Давно было замечено, что можно формально обнаружить в программе некоторые несообразности или излишества – в [7] они названы "несовершенствами", в работе [10 V. Kasjanov, I. Pottosin. Application of optimization techniques to correctness problems//Consructing Quality Software. - North-Holland, 1978. - pp.237-248] – "неправдоподобностями". В статье [11 S.Pan, R.G.Dromey. Bejond Structured Programming//Proc. ICSE-18. -Berlin. -pp.268-278] предложены правила, определяющие так называемую каноническую форму, автоматически исключающую ряд подобных несообразностей. Прагматические критерии добротности связаны с тем, что формально можно выявить некоторые свойства программы, которые содержательно трактуются как цели, достижению которых и служит программа. Такой целью может быть конечное состояние переменных, порождаемое программой, множество ее истинных (подтверждаемых программным текстом) результатов, подтверждаемые таким текстом потоки управления и информационные потоки и т.п. Развитые методы анализа программ могут обнаруживать подобные цели и находить те фрагменты и объекты данной программы, которые заведомо никак не служат достижению такой формально выявляемой цели. Наличие данных излишеств и служит основанием для того, чтобы признать программу недобротной в соответствии с прагматическими критериями. Источником таких излишеств может быть невнимание к реальным связям в программе, рудименты при неаккуратной модификации программы и т.п. – в общем, недосмотр и непрофессионализм. Итак, прагматические критерии добротности требуют, чтобы программа соответствовала своей формально выявляемой цели. Заметим, что прагматические критерии относятся скорее к компонентам, чем к системам.