Статистические данные, корректность программного обеспечения

Министерство образования и  науки Российской Федерации

Челябинский Юридический Колледж

Отделение права и ИТ

Кафедра «Информатики и ВТ»

КУРСОВАЯ РАБОТА

По дисциплине:

«Технология разработки программных продуктов»

По теме:

«Статистические данные, корректность программного обеспечения»

 

 

 

 

 

Работа защищена с оценкой: __________________________        “___”________________201 г

Выполнил: __________________   Студент гр.   “____”________________201 г. Проверил: __________________ “____”________________201 г

 

 

 

 

Челябинск

201

 

 

Содержание

Введение	3
1 Операционная семантика	4
1.1 Основные понятия	4
1.2 Семантические модели данных	5
1.3 Семантическая модель Entity-Relationship	9
1.4 Основные понятия ER-модели	10
1.5 Уникальные идентификаторы типов сущности	14
1.6 Нормальные формы ER-диаграмм	17
1.7 Первая нормальная форма ER-диаграммы	18
1.8 Вторая нормальная форма ER-диаграммы	20
1.9 Третья нормальная форма ER-диаграммы	22
2 Конструирование программного обеспечения	23
2.1 Постановка задачи	24
2.2 Проектирование решения	27
2.3 Кодирование алгоритма	29
2.4 Сопровождение программы	29
2.5 Программная документация	30
2.6 Проектирование приложений для  работы с базами данных	31
Заключение	32
Список литературы	33

 

 

Введение

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

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

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

1) изучить семантические модели  данных;

2) рассмотреть ER-модели и   диаграммы;

3) рассмотреть и привести пример  задачи, решенной с помощью конструирования программ операционный семантики;

4) Применить их на практике в программном продукте БД "Бухгалтерия"

 

 

 

 

 

 

 

1 Операционная семантика.

1.1 Основные  понятия.

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

1.2 Семантические модели данных

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

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

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

История систем автоматизации проектирования баз данных (CASE-средств3)) началась с  автоматизации процесса рисования  диаграмм, проверки их формальной корректности, обеспечения средств долговременного  хранения диаграмм и другой проектной  документации. Конечно, компьютерная поддержка  работы с диаграммами для проектировщика БД очень полезна. Наличие электронного архива проектной документации помогает при эксплуатации, администрировании и сопровождении базы данных. Но система, которая ограничивается поддержкой рисования диаграмм, проверкой их корректности и хранением, напоминает текстовый редактор, поддерживающий ввод, редактирование и проверку синтаксической корректности конструкций некоторого языка программирования, но существующий отдельно от компилятора. Кажется естественным желание расширить такой редактор функциями компилятора, и это действительно возможно, поскольку известна техника компиляции конструкций языка программирования в коды целевого компьютера. Но коль скоро имеется четкая методика преобразования концептуальной схемы БД в реляционную схему, то почему бы не выполнить программную реализацию соответствующего «компилятора» и не включить ее в состав системы проектирования баз данных?

Эта идея, естественно, показалась разумной производителям CASE-средств проектирования БД. Подавляющее большинство подобных систем, представленных на рынке, обеспечивает автоматизированное преобразование диаграммных  концептуальных схем баз данных, представленных в той или иной семантической  модели данных, в реляционные схемы, специфицированные чаще всего на языке SQL. У читателя может возникнуть вопрос, почему в предыдущем предложении  говорится про «автоматизированное», а не про «автоматическое» преобразование? Все дело в том, что в типичной схеме SQL-ориентированной БД могут  содержаться определения многих объектов (ограничений целостности  общего вида, триггеров и хранимых процедур и т. д.), которые невозможно сгенерировать автоматически на основе концептуальной схемы. Поэтому  на завершающем этапе проектирования реляционной схемы снова требуется  ручная работа проектировщика.

Еще раз обратите внимание на то, какой  ход рассуждений привел нас к  выводу о возможности автоматизации  процесса преобразования концептуальной схемы БД в реляционную схему. Если создатели семантической модели данных предоставляют методику преобразования концептуальных схем в реляционные, то почему бы не реализовать программу, которая производит те же преобразования, следуя той же методике? Зададимся теперь другим, но, по существу, схожим вопросом. Если создатели семантической модели данных предоставляют язык (например, диаграммный), используя который проектировщики БД на основе исходной информации о предметной области могут сформировать концептуальную схему БД, то почему бы не реализовать программу, которая сама генерирует концептуальную схему БД в соответствующей семантической модели, используя исходную информацию о предметной области? Хотя нам не известны коммерческие CASE-средства проектирования БД, поддерживающие такой подход, экспериментальные системы успешно существовали. Они представляли собой интегрированные системы проектирования с автоматизированным созданием концептуальной схемы на основе интервью с экспертами предметной области и последующим преобразованием концептуальной схемы в реляционную.

Как правило, CASE-средства, автоматизирующие преобразование концептуальной схемы  БД в реляционную, производят реляционную  схему базы данных в третьей нормальной форме. Нормализация более высокого уровня усложняет программную реализацию и редко требуется на практике.

Наконец, третья возможность, которую  следует упомянуть, хотя она еще  не вышла (или только выходит, а может  быть, так никогда и не выйдет) за пределы исследовательских и  экспериментальных проектов, – это  работа с базой данных в семантической  модели, т. е. СУБД, основанные на семантических  моделях данных. При этом снова  рассматриваются два варианта: обеспечение  пользовательского интерфейса на основе семантической модели данных с автоматическим отображением конструкций этого  интерфейса в реляционную модель данных (это задача примерно того же уровня сложности, что и автоматическая компиляция концептуальной схемы базы данных в реляционную схему) и  прямая реализация СУБД, основанная на какой-либо семантической модели данных. Многие авторитетные специалисты полагают, что ближе всего ко второму подходу объектно-ориентированные СУБД, чьи модели данных по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых – более слабы).

1.3 Семантическая модель Entity-Relationship

В этой лекции мы кратко рассмотрим некоторые  черты одной из наиболее популярных семантических моделей данных –  модель «Сущность-Связь» (часто ее называют кратко ER-моделью от Entity-Relationship).

Здесь следует сделать два замечания, касающиеся, главным образом, терминологии. Оба термина relation и relationship могут  быть переведены на русский язык как  отношение. Поэтому в русскоязычной  литературе ER-модель иногда называют моделью  сущность-отношение, а иногда и реляционной  семантической моделью. Наверное, в  этом нет ничего страшного, если говорить о ER-модели в отрыве от тематики проектирования реляционных баз данных.

Но если требуется одновременно использовать термины ER-модели и реляционной  модели данных, то, безусловно, требуется  применять для терминов relation и relationship разные русские эквиваленты. За этими  терминами стоят весьма различные  понятия. В реляционной модели отношение (relation) – это единственная родовая  структура данных. С помощью этого  же механизма представляются «связанные»  сущности (вспомните, например, про  внешние ключи). Как мы увидим немного  позже, в ER-модели для представления  схемы базы данных используются два  равноправных понятия – сущность и связь. Связи в ER-модели играют роль, отличную от той, какую играют отношения в реляционной модели данных.

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

На использовании разных вариантов ER-модели основано большинство современных  подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Питером Ченом (Peter Chen) в 1976 г. Моделирование предметной области базируется на использовании  графических диаграмм, включающих небольшое  число разнородных компонентов. Простота и наглядность представления  концептуальных схем баз данных в ER-модели привели к ее широкому распространению  в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз  данных. Среди множества разновидностей ER-моделей одна из наиболее популярных и развитых применялась в системе CASE компании Oracle. Мы обсудим некоторый  упрощенный вариант этой модели. Если говорить более точно, сосредоточимся на ее структурной и целостной  частях.

1.4 Основные  понятия ER-модели

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