2.3.3. Представление данных во внешней памяти.

Современные операци­онные системы поддерживают два способа организации данных во внешней памяти: последовательный и с прямым доступом.

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

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

При выборе типа памяти для размещения структур данных следует иметь в виду, что:

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

• во внешней - данные, которые должны сохраняться после завершения программы.

Возможно, что во время работы данные целесообразно хранить в опера­тивной памяти для ускорения доступа к ним, а при ее завершении - перепи­сывать во внешнюю память для длительного хранения. Именно этот способ используют большинство текстовых редакторов: во время работы с текстом он весь или его часть размещается в оперативной памяти, откуда по мере на­добности переписывается во внешнюю память. В подобных случаях разраба­тывают два представления данных: в оперативной и во внешней памяти.

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

Раздел 3. Использование декомпозиции и абстракции при объектно-ориентированном подходе к анализу и проектированию по Тема 3.1. Анализ требований к по и декомпозиция системы при объектном подходе

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

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

3.1.1. Язык uml.

Конец «войне методов» положило появление в 1995 г. первой версии языка UML (Unified Modeling Language - унифицированный язык моделиро­вания - см. приложение), который в настоящее время фактически признан стандартным средством описания проектов, создаваемых с использованием объектно-ориентированного подхода. Его создателями являются ведущие специалисты в этой области: Гради Буч, Ивар Якобсон и Джеймс Рамбо, ко­торые использовали в своем языке все лучшее, что появилось в подходах этих авторов во время «войны методов».

Спецификация разрабатываемого программного обеспечения при ис­пользовании UML объединяет несколько моделей: использования, логичес­кую, реализации, процессов, развертывания (рис. 6.2).

Модель использования представляет собой описание функциональности программного обеспечения с точки зрения пользователя.

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

Модель реализации определяет реальную организацию программных модулей в среде разработки.

Модель процессов отображает организацию вычислений и оперирует по­нятиями «процессы» и «нити». Она позволяет оценить производительность, масштабируемость и надежность программного обеспечения.

И, наконец, модель развертывания показывает особенности размещения программных компонентов на конкретном оборудовании.

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

Всего UML предлагает девять дополняющих друг друга диаграмм, вхо­дящих в различные модели:

• диаграммы вариантов использования (см. § 6.2);

• диаграммы классов, (см. § 6.3, 7.3 и 7.4);

• диаграммы пакетов (см. § 7.1);

• диаграммы последовательностей действий (см. § 6.4 и 7.4);

• диаграммы кооперации (см. § 7.3);

• диаграммы деятельностей (см. § 6.5 и 7.4);

• диаграммы состояний объектов (см. § 7.4);

• диаграммы компонентов (см. § 7.5);

• диаграммы размещения (см. § 7.6),

Все указанные диаграммы по возможности используют единую графи­ческую нотацию, что облегчает их понимание.

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

UML и предлагаемая теми же авторами методика Rational Unified Process поддерживаются пакетом Rational Rose фирмы Rational Software Corporation. Ряд диаграмм UML можно построить также средствами про­граммы Microsoft Visual Modeler и других GASE-средств. По данным «USA Today» в настоящее время 49 из 50-ти ведущих компьютерных компаний ис­пользуют UML при разработке программного, обеспечения с использованием объектного подхода, что и позволяет говорить о том, что сегодня UML фак­тически стал стандартом описания подобных разработок.