bigpo.ru
добавить свой файл
1

Подходы к разработке ПП (1, 12)



Различают 5 подходов:

  1. Метод функциональной декомпозиции

  2. Метод анализа потоков данных

  3. Метод анализа структур данных

  4. Разработка на базе абстрактных типов данных (АТД)

  5. Объектно-ориентированный подход


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

^ Разработка на базе АТД: Признаки АТД – множество допустимых значений, множество допустимых операций и правила их выполнения. Проектирование заключается в педставлении задачи на базе имеющихся типов данных (очередь, стек, список, дерево и т.д.) и операций над ними.

ОО-подход: Объект – некоторый реально существующий предмет. Класс – множество объектов с одинаковыми свойствами и одинаковым поведением. Свойства – набор переменных, характеризующих класс. Поведение класса задается методами. Между классами есть отношения .


^ Метод функциональной декомпозиции (2, 10?)


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


^ HIPO-технология, типы диаграмм, их назначение (3)


HIPO – Hierarchical Input Processing Output. Здесь процесс проектирования заключается в составлении IPO диаграмм. Каждая IPO-диаграмма соответствует одной функции. IPO-диаграммы соединены между собой иерархической связью.



frame1Перечисление структур и данных с которыми рабоатет программа


^ Связность и сцепление модулей (4)


При проектировании методом функциональной декомпозиции возникает вопрос – какие связи должны быть между подзадачами? В идеале – никаких. Используются термины: связность – связи внутри одной подзадачи; сцепление – связь между разными подзадачами.


Метод анализа потоков данных (5, 6)


Первый этап – составление диаграмм потоков данных (DFD – data flow diagram). Обозначения:



– источник (потребитель) данных, п – обработка данных,




– файл или база данных (хранилище данных), – поток данных.

DFD м.б. иерархической. Составление диаграмм носит итеративный характер. Очередность действий: 1) составление на качественном уровне; 2) уточнение состава передаваемых данных; 3) проектирование структуры базы данных; 4) эскизы форм ввода/вывода для источников и потребителей.



^

Жизненный цикл программы (7)



Опр: Программный продукт – программа + пользовательская документация. ПП можно эксплуатировать без участия его автора.


Этапы ЖЦ:

  1. Анализ

  2. Проектирование

  3. Реализация

  4. Сборка, тестирование, испытание

  5. Внедрение (выпуск)

  6. Сопровождение



Анализ


Различают 2 случая производства ПП: 1) ПП делается для конкретного заказчика. В этом случае нужно прикладную задачу преврашать в программистскую. Нужно понять как функционирует та среда, которую нужно автоматизировать (анализ бизнес-процессов). В результате появляется документация-спецификация требования, где указаны какие именно задачи д.б. решены и при каких условиях. Эту работу выполняет системный аналитик (аналитик бизнес-процессов).

2) ПП разрабатывается для рынка. Нужно проводить маркетинговые исследования и найти какого продукта на рынке нет. Это связано с большим риском. Цель – разработка спецификации требований.

Проектирование


Цель – определение общей структуры (архитектуры) ПП. Результат – спецификация ПП. Эту работу выполняет системный программист.
^

Реализация


Написание программного кода. Реализация включает и разработку, и тестирование, и документацию.

Сборка, тестирование, испытние


Сборка всего, что сделано разными программистами. Тестирование всего программного комплекса. Отладка – поиск и устранение причин ошибок. Испытание – уточнение технических характеристик. В результате – гарантия работоспособносит программы.
^

Внедрение (выпуск)


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

Выпуск – когда ПП разрабатывается на рынок. Начинается с этапа бета-тестирования. Соотв. версия – бета-версияю. Альфа-тестирование – тестирование людьми из той же организации, не участвовавших в разработке программ. Бета-тестирование – изготовление нескольких экземпляров ПП и отправка потенциальным заказчикам. Цель – еще раз проверить разработку ПП.

Если на рынок выпускается принципиально новый ПП, то возможно несколько бета-тестирований. После бета-тестирование – выпуск коммерческой версии.

Сопровождение


Устранение замеченных в ходе эксплуатации ошибок. Внесение непринципиальных усовершенствований. Накопление предложений для разработки следующей версии.


^ Модели жизненного цикла (8)


  1. Waterfall («водопад», каскадная модель)



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




  1. Прототипирование

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

  1. Итерационная модель

Задача разделяется на подзадачи и определяется очередность их реализации т.о., чтобы каждая следующая подзадачи расширяла возможности ПП. Успех существенно зависит от того сколь удачно разделены задачи на подзадачи и как выбрана очередность. Преимущества: 1) возможность активного участия заказчика в разработке, он имеет возможность уточнить свои требования в ходе разработки; 2) возможность тестирования вновь разрабатываемых частей совместно с ранее разработанными, это уменьшит затраты на комплексную отладку; 3) во время разработки можно начинать внедрение по частям.


^ Жизненный цикл «спираль» (9)


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



^ COCOMO модель (11)


Как определить сколько времени понадобится для разработки ПП? Допустим, что известен приблизительный объем разрабатываемого продукта в строках исходного текста. Этот объем может быть определен экспертным путем по аналогии с уже существующими разработками. Пусть KDL - объем разрабатываемого программного обеспечения в тысячах строк исходного текста. Трудоемкость (в человеко-месяцах) и время разработки программного обеспечения можно определить по модели COCOMO (COnstructive COst MOdel): E=a*KDL^b, где a,b - зависят от характеристик проекта:

  1. Для прикладных систем, разрабатываемых в существующих средах небольшими по численности коллективами (системы обработки данных, банковские системы): a=3.2; b=1.05.

  2. Разработка базового программного обеспечения (операционные системы, системы управления базами данных): a=3.0; b=1.12.

  3. Встроенные системы, системы реального времени, компьютерные системы навигации с высокими требованиями к надежности: a=2.8; b=1.20.

Для уточнения трудоемкости может быть дополнительно учтен ряд показателей, объединенных в следующие группы:

  1. Показатели программного продукта:

- требуемая надежность программного продукта (RELY);

- объем базы данных (DATA);

- сложность продукта (CPLX).

  1. Показатели ЭВМ:

- наличие ограничений на время выполнения (TIME);

- наличие ограничений на объем ОЗУ (STOR).

  1. Показатели разработчиков:

- компетентность системного аналитика (ACAD);

- опыт разработки прикладных систем (AEXP);

- квалификация программистов (PCAD);

- опыт работы со средой разработки (LEXP).

  1. Показатели процесса проектирования:

- использование современных методов разработки программ (MODP);

- использование инструментальных средств разработки программ (TOOL).


^ Этапы разработки программного продукта по ОО-методике (13)


  1. ОО-анализ (OOA)

Цель – понимание и описание функционирования той предметной области, для которой разрабатывается программное обеспечение. Описание осуществляется в терминах классов, объектов и отношений между ними.

  1. ОО-проектирование (OOD)

Цель – разработка структуры классов и объектов, соответствующих предметной области и позволяющих решить поставленные задачи.

  1. ОО-программирование (OOP)

Цель – реализация на языке программирования по объектно-ориентированной методике.

  1. эволюция

  2. модификация

Эволюция и развитие - это развитие и усовершенствование уже внедренного программного обеспечения.


Свойства объектно-ориентированного программирования (14)


Характерные свойства:

  1. Инкапсуляция (упрятывание) – сочетание данных с процедурами и функциями для их обработки в новый тип - объект.

  2. Наследование – определение объекта с последующим формированием иерархической структуры из подчиненных ему объектов. Каждый подчиненный объект имеет доступ к данным, процедурам и функциям вышестоящего объекта.

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


^ Объекты и отношение наследования на Паскале (15)


Объект = данные + методы

Метод м.б. реализован с помощью процедур, функций, конструкторов и деструкторов. Объекты описываются в секции type.

type

Location=object

x, y: integer

procedure Init(nx, ny: integer);

end;

var

Loc: Location;

Loc.Init(4, 6);

Возможны атрибуты доступа: private, protected, public. Наследование:

type

Point=object(Location)



end;

Множественное наследование запрещено. В объекте наследнике запрещено повторное определениепеременных предков (независимо от атрибутов). Переопределение методов разрешается. Инициировать нужно как переменные объекта, так и унаследованные переменные.

^

Статические и виртуальные методы на Паскале. Полиморфизм (16)



По умолчанию все методы статические. Статические методы будут связаны со своими объектами во время трансляции (раннее связывание). Виртуальные методы будут связываться во время выполнения (позднее связывание). Познее связывание дает основу полиморфизму.

Если в объекте имеется хотя бы один виртуальный метод, то в нем обязательно д.б. конструктор. Конструктор д.б. явно вызван до начала работы с виртуальными методами.

X=object

procedure Pr; virtual;



end

Obj=object(X)

procedure Pr; virtual;



end;

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


^ Конструкторы и деструкторы в Паскале (17)


Конструктор должен вызываться в случае динамического создание переменных типа объект. Конструктор необходим для формирования VMT, в котором задана длина объекта. Деструктор обеспечивает доступ к VMT для определения объема освобождаемой памяти. Деструктор может не иметь в своем составе операторов, тогда он обеспечивает только связь с VMT. В общем случае в деструктор желательно включить действия, необходимые перед уничтожением экземпляра объекта. Деструктор, в отличие от конструктора, может быть виртуальным. Конструктор может содержать формальные параметры, деструктор – нет.


X=object

constructor C(a, b: integer);

destructor D;

end;


^ Динамическое создание объектов на Паскале (18)

Аналогично другим переменным, переменные типа объект могут динамически создаваться и уничтожаться. Для обеспечения динамического вызова в программе должен быть указатель на объект, а сам объект должен содержать конструктор (даже тогда, когда он не содержит виртуальных методов) и деструктор. Для создания экземпляра объекта используется оператор New: New(S1,Init), где S1 – указатель на объект, Init – конструктор объекта. Для уничтожения экземпляра объекта используется оператор Dispose: Dispose(S1,Done); где S1 – указатель, Done – деструктор.


^ Таблица виртуальных методов на Паскале (19)


Если в описании объекта имеются виртуальные методы, конструкторы или деструкторы, компилятор создает специальное поле – таблицу виртуального метода VMT (Virtual Method Table). Длина поля VMT 16 битов. Оно расположено в области данных и инициализируется конструктором при его вызове. Выделение в памяти места и заполнение VMT осуществляется транслятором автоматически; программисту VMT недоступно. Структура VMT:

длина объекта

-длина объекта (отриц. число в доп. коде)

@ адреса точек входа всех виртуальных методов

VMT имеется в одном экземпляре для каждого объекта, имеющего виртуальные методы. Чтобы выполнялась проверка инициализации объекта нужно задать директиву {R+}


Особенности ООП на языке Object Pascal на Delphi (20)


В Delphi имеется 2 подхода к реализации ООП:

    1. Классический, унаследованный от Turbo Pascal 7.0 и ничем от него не отличающийся.

    2. Введены понятия «класс» и «объект». Автоматическим предшественником всех создаваемых классов является класс TObject.

type

cl1=class

end;

var

mycl1: cl1;

Здесь mycl1 – указатель на класс. Память нужно автоматически выделять. В классе обязательно д.б. конструктор.

Виртуальные методы в Delphi:

type

cl1=class

procedure Pr; virtual;

procedure Qr; virtual;



end;

cl2=class(cl1)

procedure Pr; override;

procedure Qr; virtual; {это уже другая процедура}

end;

Динамические методы: procedure Pr; dynamic. С точки зрения выполнения то же самое, что и virtual. Создается DMT (dynamic MT). В VMT адреса всех методов, даже предшественников, а в DMT включаются только адреса динамических методов, определенных только в данном классе.


^ Контейнерные классы на C++, назначение, структура (31)


КК – классы, предназначенные для хранения данных, организованных определенным образом. Например векторы, списки и т.д. Для каждого контейнера определены методы для работы с его элементами, не зависящие от конкретных типов данных, хранимых в контейнере. Есть библиотека STL – Standard Template Library. Разновидности контейнеров: последовательные (vector, deque, list, stack, queue, priority-queue) и ассоциативные (прямой доступ по ключу: map, multimap, set, multiset, bitset).


^ Последовательные контейнеры (32)


Вектор: #include , vector. С последовательными контейнерами связано понятие итератор. Это указатель на элементы КК.

vector::iterator p;

p=v.begin();

while(p!=v.end()) {cout << *p; p++;}

Есть функции: size(), empty(), push_back() – добавить в конец, pop_back(), insert(место, эл-т), erase(место), at(место). Конструкторы:

vector v;

vector v1(10, 1);

vector v2(v1);


^ Ассоциативные контейнеры (33)


Определен шаблон для создания пар значений:

template struct pair {

T1 first; T2 second;

Pair(const T1 &x, const T2 &y);

Template pair(const pair &P);
};

Операции сравнения: p1
если p1.first
или p1.first=p2.first и p1.second


Есть возможность определения критерия упорядочивания. Для этого служат функциональные классы.

Пример:

class if_greater {

public:

int operator () (int a, int b) const {return a>b;}

};

if_greater x;

cout << x(1, 5);

В ассоциативных класах можно проводить поиск по значениям элементов.

Словарь map: Элементы словаря – пары (ключ, значение). По умолчанию упорядочены по ключам. Повторение ключей не допускается.

#include

#include

using namespace std;

typedef map> months_type;

void main {

months_type months;

months_type::iterator ptr;

typedef months_type::value_type value_type;

months.insert(value_type(string(“Jun”), 31));

for(ptr=months.begin(); ptr!=months.end(); ptr++)

cout << *ptr;

ptr.months.find(string(“June”));

}

Операции сравнения: equal_to, not_equal_to, greater, greater_equal, less, less_equal, logical_and, logical_not, logical_or.

Есть обратный итератор: reverse_iterator. Функции: rbegin(), rend(). В этом случае указатель увеличивать надо так: ++p.

Функции: count(ключ) =1 если есть, =0 если нет; empty(), equal_range(ключ), erase(итератор), erase(ключ), find(ключ), insert(значение), insert(итератор, значение), lower_bound(ключ), max_size(), size(), upper_bound(ключ).

Множество set:

#include



set_union(sd.begin(), st.end(), st2.begin(), st2.end());

set_intersection(-//-)


^ Тестирование и отдладка (34)


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


^ Виды контроля программ (35)


3 вида:

  1. Визуальный. Оценка программы путем ее просмотра без применения ЭВМ. Должен выявить программистскую культуру. Можно рассказать идею человеку, не участвовавшем в разработке программы.

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

  3. Динамический. Запуск программы и тестирование.


Цели, принципы и этапы тестирования (36)


  1. Каждый тест должен сопровождаться описанием результатов.

  2. Избегать тестирование автором, особенно на заключительных стадиях (но отладка – автором).

  3. Проведение бета-тестирования, особенно ПП, предназначенного для рынка.

  4. Результаты тестирования д.б. досканально изучены.

  5. Необходимо проверить работу программы на недопустимых входных данных.

  6. Необходимо сохранить использованные тесты (чтобы не пропустить имеющиеся тесты; при установка у нового заказчика неплохо пропустить их).

Для тестирования д.б. выделены достаточные временные и материальные ресурсы. Часто имеет место принцип скопления ошибок. Если в ходе тестирования выяснилось, что ошибки в одной части прогарммы, то часто оказывается, что там их еще много.

Тестирование – творческий процесс. Главная задача тестирования – нахождение ошибок. Существует 2 подхода к тестированию: 1) функциональное (тестирование по данным, тестирование черного ящика) – структура программы не учитывается, 2) структурное (тестрование управления, тестирование белого ящика) – известна структура программы и проектируются тесты в зависимости от управленческих структур.

Тестирование проводят по следующим уровням:

  1. Тестирование отдельных процедур и функций.

  2. Совместное тестирование процедур и функций.

  3. Тестирование функций программного комплекса.

  4. Тестирование всего комплекса в целом.

На 1 и 2 может применяться структурное тестирование, на последних – функциональное. Если логика программы очень сложная, то надо провести тщательное структурное тестирование. Особая опасность в компбинациях разных условий.


^ Структурное тестирование (37)


Известна структура программы и проектируются тесты в зависимости от управленческих структур. Тестирование проводят по следующим уровням.

Самый слабый критерий – составление таких тестов, чтобы каждый оператор выполнялся хотя бы один раз. Если есть блок-схема программы, то составляются тесты так, чтобы каждая ветвь выполнялась хотя бы один раз (при условии, что каждый условный блок содержит одно условие). Более сильный критерий – комбинаторное покрытие условий и решений: должны тестироваться все варианты условий и решений.

Пример: if (A>1) and (B=0) then C:=C/A;

if (A=2) or (C>1) then C:=C+1;


A>1 B=0 A>1 B<>0 A<=1 B=0 A<=1 B<>0 A=2 C>1 A=2 C<=1 A<>2 C>1 A<>2 C<=1

Составляется минимальное множество тестов, чтобы покрыть все эти случаи:

A

B

C

2

0

4

2

1

1

1

0

2

1

1

1


^ Функциональное тестирование (38)


3 способа:

  1. Метод эквивалентного разбиения. Теоретически нужно тестировать на всех возможных данных. Все множество значений исходных данных разделяем на подмножества и предполагаем, что из каждого множества достаточно взять 1 значение (это классы эквивалентности). Различают правильные и неправильные классы эквивалентности (по допустимости исходных данных). Минусы: если исходных данных много, то трудно построить классы эквивалентности.

  2. Метод граничных значений. Выявление путем анализа задачи. Рекомендуют проверить граничные условия по выходу. Общий недостаток – трудность отслеживание исходных данных.

  3. Метод функциональных диаграмм. Состоит из 6 этапов:

а) разделение внешней спецификации на отдельные независимые участки

б) выделение причины и следствия (причина – те или иные исходные данные, следствие – результат)

в) составление собственно функциональной диаграммы (ФД)

г) на ФД заносятся ограничения, связанные с допустимыми и недопустимыми значениями исходных данных

д) ФД преобразуется в таблицу решений

е) таблица решений преобразуется в тесты

Метод эффективен если много исходных данных и накладываются сложные условия.

Пример:



На форме есть два текстовых окна. В 1-й позиции буквы A или B, во второй – любая цифра. Тогда файл обновляется. Если в 1-й позиции неправильный символ – выдается сообщение X12, если во второй, то X13.

Причины: 1) в 1-й позиции буква A; 2) в 1-й позиции буква B; 3) во 2-й позиции цифра

Следствия: 70 – факт обновления; 71 – выдается сообщение X12; 72 – выдается сообщение X13

Функциональная диаграмма:



Используют обозначения:



Анализ ФД: ставим некоторое следствие в состояние 1 и двигаясь от него назад определяем все комбинации входов при которых выбрано следствие 1 и определяем значения других выхдов. Для каждой комбинации выходов сооставляем 1 тест. При движении назад рекомендуют соблюдать следующие рекомендаци: 1) если ведет несколько путей, соединенных через , то не рекомендуют устанавливать 1 более одной причины (чувствительность тестов); 2) если 2 пути через &, то рекомендуют проверять комбинации 00 и 01 или 10.

70

71

72

H

1

2

3

1

0

0

1

0

1

1

0

0

1




1

0

0

0

1

0

0

0

0

0


^ Совместное тестирование модулей (39)


Есть 2 подхода: 1) монолитное тестирование – каждый модуль тестироуется отдельно, а затем выполняется сборка программы (требуется построение заглушек и драйверов); 2) пошаговое тестирование – каждый модуль подключается к ранее протестированным модулям.

В (2) могут использоваться восходящее и нисходящее тестирование.

При (1) трудозатраты больше, т.к. надо писать драйверы и заглушки.

В (2) раньше всплывают ошибки интерфейса. При (1) они могут всплывать на заключительной стадии.

Результат (2) более совершенен.

Расход машинного времени при (1) как правило меньше, т.к. запускаются только тестируемые модули. При (1) легче распараллелить работу.

Предпочтительнн пошаговое тестирование с применением монолитного для модулей особо важных или особо сложных.

^ Нисходящее тестирование

+: 1) более раннее формирование структуры комплекса в целом (это нравится начальству)

2) легче обнаружить ошибки в верхней части программы

3) т.к. ввод/вывод данных обеспечивается врхними уровнями, то легче организовать тестирование

–: 1) необходимо писать заглушки и драйверы

2) трудно создать тестовые условия для нижних модулей

3) сложно оценить результаты тестирование, особенно модулей нижнего уровня

4) стимулируется сдача незавершенной программы

Для восходящего тестирования с точностью до наоборот.


^ Тестирование и испытание программного комплекса в целом (40)


Нормальная программы должна эксплуатироваться без присутствия автора. Испытание программы включает следующие этапы:

  1. Испытание удобства использования.

  2. Тестирование на предельных объемах.

  3. Тестрование на предельных нагрузках.

  4. Тестирование защиты о несанкционированного доступа.

  5. Тестирование производительности.

  6. Испытание требований к оборудованию.

  7. Испытание совместимости с ранее внедренными программами.

  8. Испытание надежности.

  9. Испытание удобства установки.

  10. Испытание средств восстановления.

  11. Критический анализ пользовательской документации.


Цикломатическое число программы, тестирование путей (41)


Составляется управляющий граф программы. Определяются все пути, ведущие из начальной точки в конечную и подбираются тести так, чтобы все пути были пройдены. Но при этом количество возможных путей растет быстро и пути могут оказаться несовместимыми, т.е. невозможно подбирать исходные данные так, чтобы все пути были пройдены. Есть 3 стратегии тестирование: 1) выписывание всех путей; 2) определение цикломатического числа графа (оно определяет количество путей, которые нужно протестировать); 3) однократная проверка всех циклов в совокупности с ациклическими участками.


^ Отладка программы (42)


Выявление и устранение причин ошибок. Иногда говорят об индуктивном и дедуктивном методе отладки. Если возникает ошибка, то нужно выявить причину ее возникновения и в будущем так не делать.

^ Создание баз данных в Delphi (53)


Базы данных реализуются с помощью компоненты Database desktop (Tools  Database desktop).

File  New  Table (тип данных Paradox 7.0).


Доступ к базам данных в Delphi (54)


Есть 3 уровня обработки БД: 1) стандартные средства Delphi, 2) использование SQL, 3) программа на Паскале.

^ Представление одного файла в виде таблицы: вкладка Data Access  Table. Свойства: DataBaseName, TableName, Active (FT), Filter, Filtered.

Представление данных формами: Data Controls: DBGrid, DBNavigator, DBText, DBEdit, ….

Использование SQL: Data Access  Query. Свойства: DataBaseName, SQL, Active.

Средства Паскаля используются когда: а) данные должны быть обработаны по особому алгоритму, не связанному с поиском данных; б) кнопки для манипуляции над данными.


^ Язык и методика объектно-ориентированного анализа и проектирования UML (56)




Логическое представление – представление с точки зрения конечного пользователя. Включает внешние и внутренние структурные отношения.

^ Представление реализации – для программиста. Включает отношения между программами или компонентами.

Представление процесса функционирования – для системного интегратора.

Представление размещение – представление системного администратора.

Цель разработки UML – предоставить в распоряжение пользователей легко воспринимаемый и выразительный язык визуального моделирования, предназначенный для разработки и документирования моделей сложных систем. В основе UML лежат диаграммы. Определены следующие виды диаграмм:

    1. Диаграмма вариантов использования (use case diagram)

    2. Диаграмма классов (class diagram)

    3. Диаграммы поведения (behavior diagrams)

а) диаграммы состояний (state chart diagram)

б) диаграмма деятельности (activity diagram)

в) диаграммы взаимодействия (interaction diagrams)

      • диаграмма последовательности (sequence diagram)

      • диаграмма кооперации (collaboration diagram)

    1. Диаграммы реализации (implementation diagram)

а) диаграмма компонентов (component diagram)

б) диаграмма развертывания (deployment diagram)



Пакет – логическая составная часть анализируемой системы. Между пакетами возможно отношение зависимости.

При внесении изменений в пакет B нужно проанализировать к чему это приведет в A. Изменения в A на B не влияют.

1-й уровень анализа – разбиение системы на пакеты.


^ Диаграмма вариантов использования (57)


Цели: 1) Определение общих принципов и контекста моделируемиой предметной области на начальных этапах проектирования.

2) Сформулировать общие требование к функциональному поведению проектируемой области.

3) Разработать исходную концептуальную модель для ее следующей детализации.

4) Подготовка исходной документации для взаимодействия с заказчиком.

Используются обозначения:

Действующее лицо (actor, актер) – тот кто со своим запросом обращается к проектироемому программному комплексу. 3 разновидности: человек, какое-то техническое устройство, для управления которым создается ПК, другой ПК, внешний к данному.

Варианты использования

Отношения:

^ Отношение ассоциации: служит для обозначения специфической роли актера в отдельном варианте использования, т.е. какую конкретную роль играет актер при взаимодействии с экземпляров варианта использования.

^ Отношение обобщения: служит для указания факта, что некоторый вариант использования может быть обобщен до другого варианта использования.

Отношение расщирения: определяет связь одного варианта использования с более общим.

^ Отношение включения: показывает, что некоторый вариант использования включает в себя подварианты.


Диаграмма последовательности и кооперативная диаграмма (58)


В ходе работы программы объекты обмениваются сообщениями. Сообщение – законченный акт передачи информации от одного оъекта к другому. Рассмотрим 2 аспекта: 1) временной – в какой очередности сообщения передаются между объектами; 2) структурный – как сообщение между объектами м.б. переданы. По сути передача сообщения означает, что объект одного класса вызывает метод объекта другого класса. Обычно на диаграмме указывают объекты, а не классы. Но если все объекты ведут себя идентично, то можно написать имя класса (:имя класса). Каждый объект обладает линией жизни. Если она заканчивается крестиком, то в этот момент времени объект уничтожается. Если на ней нарисован прямоугольник, то это значит, что объект в это время действует.

Диаграмма коопераций – вариант диаграммы последовательности откуда почти исключено время.




^ Диаграмма классов, характеристика классов (59)


Объект – реально существующий предмет в предметной области. Класс – множество объектов, обладающих одинаковыми свойствами о одинаковым поведением (по меньшей мере в анализируемой ситуации).

Диаграмма классов служит для представления статической структуры модели системы в терминологии классов. Характеристики классов: имя класса, данные, методы. На стадии анализа можно ограничиться качественным перечислением данных и названий методов.


^ Отношение между классами на диаграмме классов (60)


Отношение зависимости: указывает некоторое отношение между двумя элементами модели или двумя множествами элементов.



^ Отношение обобщения: описывает иерархическое строение классов и наследование их свойств и поведения.



^ Отношение ассоциации: показывает содержательную связь между объектами классов.

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



^ Отношение композиции: частный случай отношение аггрегации (если A и B состоят в этом отношении, то B не может существовать без A).

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


^ Диаграмма состояний (61)


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

В любой момент врмени класс может находиться в одном состоянии. Переход от одного состояния в другое скачкообразный. Переход должен сопровождаться изменением значения хотя бы одной переменной из данных класса. Классы могут переходить из одного состояние в другое самостоятельно или под внешним воздействием. Переход класса из одного состояния в другое – событие (event). Событие = условие возникновения + параметры. В общем случае над них накладываются ограничения. М.б. диаграмма состояний с диаграммой подсостояний.

Диаграмма состояний непосредственно не используется для генерации кода. Нужна для лучшего понимания.

Возможен табличный способ представления.





События

1

2

3

4

A

B



C

*

B















– - событие произойти не может

* - событие может произойти, никакого эффекта


^ Диаграммы пакетов и компонентов (63)


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

Компонента – единица физической реализации системы.



Все классы нужно прикрепить к компонентакм и все компоненты к узлам обработки. Компоненты взаимодействуют с собой через интерфейс (обозначается кружочком, присоединяется сплошной линией).

Эта диаграмма мало зависит от среды реализации.


^ Диаграммы размещения (64)


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

Узел – некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом. Изображается в виде куба.


^ Диаграмма деятельности (65)


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




^ Rational Rose (68)


RR – CASE (Computer Aided Software Engineering) средство. Базируется на UML. Позволяет документировать результаты анализа, выполнять ОО-проектирования, выявлять некоторые формальные ошибки в созданных моделях и позволяет генерировать программы на языках C++, Visual Basic, Java, а также схемы баз данных. Это есть прямое проектирование (forward engineering). Также есть и обратное проектирование (reverse engineering, re-engineering).

Генерация программы состоит из следующих этапов: 1) проверка модели, 2) создание компонентов, 3) отображение классов на компонентах, 4) уточнение свойств генерации программы, 5) выбор класса (компонента) для генерации, 6) генерация кода.


^ Показатели качества программных продуктов, общая характеристика (69)


6 групп:

  1. Функциональная пригодность:

а) пригодность для применения

б) точность

в) защищенность

г) способность к взаимодействию

д) согласованность со стандартами и правилами проектирования

  1. Надежность

а) уровень завершенности (отсутствие ошибок)

б) устойчивость к ошибкам

в) перезапускаемость

  1. Применимость

а) понятность

б) обучаемость

в) простота использования

  1. Эффективность

а) ресурсная экономичность

б) временная экономичность

  1. Совпровождаемость

а) удобство анализа

б) изменяемость

в) стабильность

г) тестируемость

д) переносимость

е) адаптируемость

ж) структурированность

з) замещаемость

Есть 2 подхода к обеспечению качества: 1) проверять качество каждого изделия; 2) разработать такие технологические процесса, изготавливание по которым заведомо гарантируют требуемое качество.


Надежность программных продуктов (70)


Есть 3 показателя: 1) вероятность отказа, 2) ремонтопригодность, 3) длительность эксплуатации. Главная причина ненадежности программы – ошибки при написании. Различают понятия сбой и отказ. Сбой – потеря работоспособности программы на время T. Надежность программы определяется отсутствием ошибок.