Файл: Основы проектирования программ. Этапы создания программного обеспечения (Обобщенная характеристика процесса разработки программного обеспечения).pdf

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

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

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

Конкретная CASE-технология включает в себя методологию проектирования и инструментальные средства анализа и моделирования.

Архитектуру CASE-средства можно представить в виде совокупности шести компонентов (рис.4): репозиторий данных, графический редактор диаграмм, верификатор диаграмм, генератор отчётов, администратор проекта, сервис.

Рисунок 4 – Компоненты CASE-средства

При рассмотрении разнообразных CASE-систем можно выделить CASE-системы двух поколений:

1. Первое поколение. Обеспечивает:

• поддержку графических моделей;
• проектирование словарей данных;
• проектирование спецификаций;
• проектирование экранных редакторов.

2. Второе поколение. Обеспечивает:

• автоматическую кодогенерацию;
• генерацию документов по проекту;
• информационную поддержку управления проектированием;
• контроль на соответствие стандартам по всем этапам ЖЦ;
• поддержку графических представлений;
• поддержку контроля и анализа системной информации;
• поддержку представлений спецификаций проектирования;
• поддержку тестирования, верификации и анализа сгенерированных программ;
• построение прототипов и моделей системы.

Большая часть подобных технологий основывается на методологиях структурного и объектно-ориентированного анализа. Представление полученных данных производится при помощи текстов и диаграмм.

В качестве примеров можно выделить следующие популярные CASE-средства:

• ARIS Express;
• CA ERwin Data Modeler;
• Visual Paradigm for UML;
• CA ERwin Process Modeler.

Программа ARIS Express принадлежит к семейству средств моделирования ARIS компании IDS Scheer.

---

CA ERwin Data Modeling представляет собой среду моделирования данных. CA ERrwin Data Modeler позволяет проектировать структуру баз данных в нотациях IDEF1x, IE и Dimensional, генерировать SQL-код разработанной базы данных, осуществлять прямое и обратное проектирование, составлять различные отчёты.

Visual Paradigm for UML относится к профессиональным инструментам работы со стандартом UML. При помощи встроенного функционала данный пакет способен поддерживать весь рабочий цикл программы: анализ, ориентированный на объекты, дизайн, ориентированный на объекты, конструкция, тестирование и разработка.

CA ERwin Process Modeler является инструментом позволяющим моделировать, анализировать, документировать и оптимизировать бизнес-процессы. Данный продукт поддерживает такие нотации как: IDEF-0, IDEF0, IDEF3, DFD, FEO, Swimlane [5].

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

2.2. Проектирование базы данных

Проектируемая программа определяет хранение определенной информации. Лучшим вариантом хранения данных является использование реляционных баз данных. Реляционная база данных – база данных, основывающаяся на реляционной модели. Слово «реляционный» произошло от английского слова «relation» (отношение). Для того, чтобы работать с реляционными базами данных, как правило, применяют реляционные системы управления БД. Первым, кто стал инициатором применения таких БД еще в 1979 г., стал профессор Кодд, который работал в корпорации IBM [11].

Реляционная модель организует данные в виде двумерных таблиц.

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

Больше всего распространились серверы реляционных БД, которые базируются на клиент-серверной архитектуре. Данными серверами обеспечивается устойчивая работа с базами данных сразу множества клиентов (ими могут являться десятки, сотни, а также тысячи и млн. клиентов – все зависимо от применяемого оборудования и ПО). Помимо того, реляционная модель данных реализуется так называемыми настольными базами данных, к примеру, dBASE, FoxPro, а также Clarion и Paradox, Access. Почти каждая ведущая настольная БД на данный момент поддерживает возможность работать как клиенты серверов БД с помощью технологий ODBC, а также BDE, ADO и других.

---

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

В таблице реляционной БД не могут содержаться повторяющиеся записи (строки). Данное требование следует из теории множеств. Наименьший набор полей, дающий возможность отличия записи от любой иной записи — ключ. Все значения ключа в рамках таблицы должны являться уникальными. Каждая таблица должна обладать хотя бы одним ключом, что прямо вытекает из того, что в таблице не могут содержаться повторяющиеся записи. Ключи таблицы могут включать одно поле – эти ключи носят название атомарных или простых ключей. Ключи могут включать несколько полей, то есть составные ключи. Таблица БД может обладать одним ключом или несколькими ключами. Один из ключей назначают как первичный ключ, а остальные — потенциальные (в теории реляционных БД) либо альтернативные (в определенных реализациях отдельных БД) [10].

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

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

---

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

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

Также отметим, что концептуальное проектирование – это сбор, анализ и корректировка требований к информации, состоящей из ряда положений:

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

Завершение концептуального проектирования заключается в разработке концептуальной модели, которая будет инвариантна к структуре БД, и сможет представляться как модель «сущность–связь».

Для изображения концептуальной модели БД в виде графической схемы разработан ряд специальных языков. Так, в 1976 г. Питер Пин-Шэн Чен предложил для этих целей специальный язык диаграмм «сущность-связь» (ER-диаграммы).

Основными конструктивными элементами модели «сущность-связь» (entity-relationship model, ER-model) являются сущности, их свойства (атрибуты) и связи между сущностями.

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

---

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

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

Большая часть существующих сегодня методик для создания БД, за основу берет различные ER–модели. Таким образом, моделирование предметной области опирается при своем создании применение графических диаграмм, включающих сравнительно маленькое количество элементов [5].

Основными понятиями ER–модели являются сущность, связь и атрибут. Сущность – это реальный или представляемый объект, информация о котором должна быть сохранена и доступна. В диаграммах ER–модели сущность представлена в виде прямоугольника, который содержит имя сущности. Каждый экземпляр сущности должен отличаться от любого другого экземпляра той же сущности. Связь представляет собой ассоциацию, которая представлена в графическом виде и установлена между двумя сущностями. Каждая связь имеет два конца. На каждом обязательно указывается имя и степень конца связи и обязательность связи. В качестве атрибута сущности выступает деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Запись имен атрибутов производится в прямоугольник, изображающий сущность, под именем сущности и изображающийся маленькими буквами [6].

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

Глава 3. Тестирование и отладка программного обеспечения

В проектах по разработке программного обеспечения помимо основной задачи по реализации заявленной функциональности существует не менее важная задача по обеспечению качества ПО. Качество ПО (Software quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

---