Представление программ и реализация вычислений
Прежде, чем передать код программы на обработку компилятору, программист должен соответствующим образом оформить код программы. В этом разделе даются общие правила оформления кода программы на разных языках программирования.
2. Основные принципы объектно-ориентированной парадигмы.
Объектно-ориентированная парадигма программирования является одной из наиболее часто используемой в практике разработки программных систем средней и высокой сложности. Основу объектно-ориентированного подхода составляет выделение объектов предметной области и структурирование системы как совокупности программных моделей этих объектов. При этом в задачах даже невысокой сложности всегда можно найти множество сущностей разного уровня детализации и абстракции. Выявленные сущности могут быть достаточно очевидны даже несведущему в компьютерных науках. Примеры подобных объектов: «заказчик», «счет», «товар», «графическое окно», «квитанция», «файл» и т.п. Для перечисленных объектов очень легко сопоставить реальные объекты из предметной области. Некоторые объекты не имеют явного аналога в предметной области, но с точки зрения разработчика также могут оказаться необходимы. Примерами могут быть такие объекты, как «динамический список», «субъект», «поток», «вариант решения»… Необходимость в подобных объектах не всегда сразу очевидна, но они позволяют обеспечивать гибкость всей системы используемых объектов за счет построения отношений иерархии, целостно хранить промежуточные результаты обработки, часто незаметные пользователю, интегрировать в себе определенные этапы обработки данных в программе.
Вариативность объектов, которые можно идентифицировать в решаемой задаче может поставить проблему – что достойно быть оформлено в виде объекта, а что нет, какой степени детализации описания необходимо придерживаться при выделении сущностей, насколько простыми или сложными должны быть объекты. Безусловно, для всякой конкретной задачи ответы на эти вопросы будут индивидуальны. Однако, существуют базовые концепции объектно-ориентированного анализа и программирования, которые должны стать базовыми ориентирами, методологической основой сначала декомпозиции, а затем и программной реализации задачи.
Основными концепциями объектно-ориентированного анализа и программирования являются принципы:
абстрагирования;
инкапсуляции;
иерархия;
модульность.
Абстрагирование подразумевает собой процесс изменения уровня детализации программы. Основная его роль [Буч] – выделение существенных характеристик некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четкое определение его концептуальных границ с точки зрения наблюдателя.
Объекты реального мира, с которыми приходится иметь дело разработчику программной системы, зачастую многогранны, обладают большим числом характеристик и сложным поведением. При этом не все это многообразие существенно с точки зрения специфики решаемой задачи. Когда мы абстрагируемся от проблемы, мы предполагаем игнорирование ряда подробностей с тем, чтобы свести задачу к более простой. Задача абстрагирования и последующей декомпозиции типична для процесса создания программ. Декомпозиция используется для разбиения программ на компоненты, которые затем могут быть объединены, позволив решить основную задачу, абстрагирование же предлагает продуманный выбор таких компонент. Последовательно выполняя то один, то другой процесс можно свести исходную задачу к подзадачам, решение которых известно. Для одного и того же моделируемого в программе объекта в зависимости от решаемой задачи необходимо учитывать различные свойства и характеристики, то есть рассматривать его на различных уровнях абстракции.
Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу объектно-ориентированного анализа. Успех решения этой задачи влияет на компактность и лаконичность описания программной системы, а также на степень ее соответствия ожиданиям заказчика.
Описание одновременно и поведения, и состояния объекта, а также ограничение доступности извне некоторых атрибутов программного объекта составляют в совокупности принцип инкапсуляции.
Инкапсуляция есть объединение в едином объекте данных и кодов, оперирующих с этими данными. В терминологии объектно-ориентированного программирования данные называются членами данных (data members) объекта, а коды - объектными методами иди функциями-членами (methods, member functions). Методы отвечают за поведение объекта, в них заключены те действия, которые объект может выполнить. Сообщения объекту поддерживаются с использованием механизма передачи параметров вызываемому методу. Члены данных отвечают за состояние объекта, их используют для фиксации тех характеристик, что были выделены на этапе абстрагирования.
Инкапсуляция является важным принципом ООП, организующим защиту информации от ненужных и случайных модификаций, что обеспечивает целостность данных и упрощает отладку программного кода после изменений.
Наследование (иерархия) состоит в процессе создания новых объектов (потомков) на основе уже имеющихся объектов (предков) с передачей их свойств и методов по наследству. Наследование позволяет модифицировать поведение объектов и придает объектно-ориентированному программированию исключительную гибкость.
Очень часто выявленные в при анализе задаче сущности имеют ярко выраженную иерархичную природу взаимоотношений. Эта иерархия может проявляться в виде отношений «общее»-«конкретное» или «целое»-«часть». В качестве примеров первого типа отношений можно привести абстракции Фигура-Квадрат, Окно – Диалоговое окно, Субъект-Студент. Второй тип отношений можно проиллюстрировать парами сущностей: Окно – Кнопка, Фигура – Точка, Web-страница – Заголовок.
Преимущество принципа наследования заключается в повторном использовании кода, когда каждый новый объект не создается с нуля, а строится на фундаменте уже существующего объекта. При этом уменьшается как размер кода, так и сложность программы. Необходимо отметить, что распространенная идея представить наследование как эволюционное развитие объектов в процессе анализа и проектирования на уровне восприятия «общее»-«конкретное» встречает критику у некоторых авторов. Так, например, в [Непейвода] наследование предлагается трактовать как функциональное обогащение базового класса классом-наследником, поскольку предоставляемые объектно-ориентированными языками программирования возможности переопределения в производном классе методов и данных их предков может нарушать логику наследования как конкретизации классом-наследником понятийной сути базового класса.
Принцип модульности представляют собой физическую декомпозицию программной системы на отдельные фрагменты (модули) с различными частями кода. Целью подобной декомпозиции должно стать эффективное структурирование программного кода с минимизацией связей между отдельными модулями программы, повышения потенциала повторного использования кода модулей, упрощение документирования программной реализации проекта.
3. Наследование и агрегация как реализации принципа иерархии в ООАиП.
4. Анализ и проектирование программного обеспечения: .цели, классификация.
5. Структурный анализ программных систем: основные принципы, существующие методологии.
6. DFD-диаграммы: .назначение, нотация, примеры реализации.
Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления [3]— продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. В результате построения диаграммы аналитик получает сеть (граф), узлы которой представляют выполняемые процессы, поставщиков и потребителей данных, хранилища данных, а соединяющие их направленные стрелки (ребра) описывают передаваемые потоки данных.
Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Рассмотрим основные графические обозначения, приняты в каждой из этих нотаций.
Таблица 1. Основные элементы диаграммы потоков данных
| Элемент | Нотация Йордона-ДеМарко | Нотация Гейна-Сэрсона |
| Поток данных | 
|
|
| Процесс | 
| 
|
| Хранилище | 
| 
|
| Внешняя сущность | 
| 
|
Потоки данных моделируют процесс передачи информации из одной части системы в другую. Потоки данных могут связывать два процесса обработки информации или процесс обработки данных с хранилищем данных. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление передачи информации, а имя отражает тип или назначение передаваемой информации.
Активным элементом схемы является процесс. Назначение процесса состоит в обработке входных потоков и формировании на их основе выходных в соответствии с действием, задаваемым именем процесса. Это имя обычно содержит описание выполняемых процессом действий. С учетом того, что структурная декомпозиция представляет собой разбиение по действиям, название должно состоять из глагола в неопределенной форме с последующим дополнением (например, Сформировать отчет, Вычислить стоимость, Найти среднее значение). Процессы индексируются уникальным номером в рамках диаграммы. Этот номер в совокупности с именем самой диаграммы может служить уникальной ссылкой на процесс в рамках всей модели.
Объект схемы, называемый хранилищем (накопителем) данных указывает, в каком месте (на каком этапе обработке) данные подлежат сохранению в памяти после обработки одним из процессов. Хранилище инвариантно по времени и порядку извлечения информации: после сохранения данных они хранятся сколь угодно долго и извлекаются в произвольный момент времени. Имя хранилища должно указывать на его содержимое и определяется именем существительным.
Еще один тип элементов DFD-диаграммы – внешняя сущность или терминатор. Объекты этого типа описывают сущность, лежащую вне контекста системы, которая не входит в состав системы и является источником или приемником данных. Ее имя задается существительными, например, Заказчик, Банк, Склад. Объекты, представленные такими узлами, с точки зрения DFD-диаграммы пассивны, они не участвуют в обработке информации.
7. Диаграммы переходов состояний (STD): назначение, нотация, примеры реализации.
Для описания динамики поведения системы в структурном анализе используются STD-диаграммы (State Transition Diagrams, диаграммы перехода состояний). Диаграммы этого типа отражают изменение состояния объекта с течением времени. Если стрелки на DFD-диаграмме отражают существование взаимодействия и передачу данных между процессами в принципе, то STD-диаграмма призвана показать, как эти взаимодействия разворачиваются во времени. Базовыми понятиями, которыми оперируют диаграммы этого типа, являются состояние и переход.
Нотация STD-диаграмм близка математическому аппарату абстрактных автоматов, что позволяет эффективно формализовать их описание.
8. Объектно-ориентированный анализ: базовые принципы, методология.
9. Язык UML: назначение, структура, нотация.