16. Class avto {

17. public:

18. avto() : cena(18700), rashod(7.2), name("Ford")

19. { cout <<"Hello from avto !!!"<< endl; }

20. ~avto() { cout <<"Object avto destroy !!!"<< endl; }

21. void OutPut() { cout <<"CENA="<< cena << endl <<

22. "MARKA="<< name << endl <<"RASHOD="<< rashod <<

23. endl <<"DATE VYPUSKA -> "; date_vypuska.OutPut(); }

24. private:

25. char* name;

26. int cena;

27. double rashod;

28. Date_Avto date_vypuska;

29. };

30. Int main()

31. {

32. avto A; A.OutPut();

33. cout <<" ***** +++++ "<< endl;

34. Date_Avto B; B.OutPut();

35. cout <<" +++++ ***** "<< endl;

36.return 0;

37. }

В строках с 3 по 15 включительно определен класс Date_Avto. В этом классе определены явныйконструктор, явныйдеструктор и методOutPut() (см. стр. 5-10) для вывода на экран даты, сформированной на основе значений трех полей (day, month, year).

В строках с 16 по 29 включительно определен класс avto. В этом классе определеныявныйконструктор, явныйдеструктор и методOutPut() (см. стр. 18-23) для вывода значений 4 полей класса.

Отметим, что вызов явного конструктора класса Date_Avto автоматически выполняется неявным конструктором класса avto, и только затем выполняется явныйконструктор класса avto.

“Расформирование” (уничтожение) объекта класса avto начинается с запуска явного деструктора этого класса. Затем во время выполнения неявного деструктора класса avtoзапускается явный деструктор класса Date_Avto.

18 Сложность больших программных систем.

В книге одного из самых известных и уважаемых специалистов в области объектно-ориентированной методологии Гради Буча “Объектно-ориентированный анализ и проектирование с примерами приложений на С++” глава, посвященная проблеме сложности программного обеспечения, начинается с изложения следующей истории:

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

Сложность присуща всем большим программным системам в том смысле, что с ней можно справиться, но избавиться от нее нельзя. Выделяют следующие четыре основные причины, по которым, программное обеспечение (ПО) обладает таким свойством как сложность:

1. сложность реальной предметной области, для которой разрабатывается программное обеспечение;

2. трудность управления процессом разработки;

3. необходимость обеспечить достаточную гибкость программы;

4. проблема описания поведения больших систем.

Говоря о сложности реальной предметной области, следует отметить, что проблемы, которые пытаются решить с помощью ПО, часто содержат сложные подзадачи, а к соответствующим программным комплексам предъявляется большое число различных, нередко взаимоисключающих требований. Кроме того, практически всегда возникают “тонкие” места, связанные с взаимодействием между пользователями системы и ее разработчиками, поскольку пользователи с трудом могут объяснить в полном объеме и в понятной разработчикам форме, что же в конечном итоге необходимо сделать. Дополнительные сложности возникают и в результате изменений требований к программной системе уже в процессе разработки и внедрения.

Трудность управления процессом разработки связана с тем, что реализация программной системы предполагает привлечение коллектива разработчиков, а потому неизбежно возникают проблемы, связанные с организацией коллективной разработки. При коллективном выполнении проекта главной задачей руководства является поддержание единства и целостности разработки.

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

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