Проектирование программного продукта ИС

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

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

ѕ степень автоматизации проектных работ;

ѕ принятая методология процесса разработки.

По степени автоматизации проектирования алгоритмов и программ можно выделить:

ѕ методы традиционного (неавтоматизированного) проектирования;

ѕ методы автоматизированного проектирования (CASE-технология и ее элементы).

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

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

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

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

Проектирование концептуальной модели

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

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

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

Наряду с этим существуют взаимосвязи между атрибутами объекта. Различают взаимосвязи типа: «один к одному», «один ко многим», «многие ко многим» .

Самой популярной моделью концептуального проектирования является модель «сущность-связь» (ER-модель), она относится к семантическим моделям.

Основными элементами модели являются сущности, связи между ними и их свойства (атрибуты).

Сущность — это класс однотипных объектов, информация о которых должна быть учтена в модели.

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

Атрибут — характеристика (параметр) не которой сущности.

Домен — множество значений (область определения атрибутов).

У сущностей выделяются ключевые атрибуты — ключ сущности — это один или более атрибутов, уникально определяющих данную сущность С помощью ER-моделирования составим концептуальную модель.

Рисунок 1 — Концептуальная модель БД «Ювелирная мастерская».

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

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

В нашем случае получаем следующую диаграмму действий (рис.2).

Рисунок 2? Диаграмма деятельности по редактированию справочника клиентов.

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

Словарь сущностей концептуальной модели

Таблица 2

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

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

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

Рисунок 3 — диаграмма прецедентов.

Проектирование логической модели

На данном этапе происходит отображение концептуальной схемы БД в логическую схему БД, которая структурирует данные в понятиях базовой модели данных СУБД, например в понятиях реляционной или сетевой модели данных. программный база данный операционный В результате логического проектирования создается спецификация отображения «концептуальная схема — логическая схема», или, более коротко, КЛ-отображения, с помощью которого генерируется логическая схема БД. Данная спецификация ставит в соответствие каждому концептуальному элементу и свойству фрагмент логической структуры БД.

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

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

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

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

Рисунок 4 -Логическая модель БД «Ювелирная мастерская».

Проектирование физической модели

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

Таблица 1 Master

Таблица 2 Razryad mastera

Таблица 3 Zakazchik

Таблица 4 Metall

Таблица 5 Kamen

Таблица 6 Izgotovlenia

Таблица 7 Izdelia

СУБД Microsoft Access на сегодняшний день является одной из самых популярных настольных программ для создания информационных систем. Это связано с тем, что Access предоставляет очень широкие возможности для ввода, анализа и представления данных. Эти средства являются не только удобными, но и продуктивными, что обеспечивает высокую скорость разработки приложений Исполнение Microsoft Office Access 2009/ Специальное издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2011.

Access обладает рядом уникальных возможностей:

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

Современные тенденции в развитии информационных технологий — интенсивное внедрение Web-технологий Internet, также получили представление в Access. СУБД Access обеспечивает публикацию баз данных в формате, доступном в сетях Internet и intranet. В Microsoft Access 2003 эти средства получили дальнейшее развитие и позволяют конструировать в интерактивном режиме Web-страницы, предназначенные для работы с базами данных.

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

Все эти и многие другие возможности СУБД Access позволяют сделать выбор в пользу Access. Основное назначение базы данных — хранение, поддержание в актуальном состоянии данных больших объемов, необходимых в различных приложениях многих пользователей — полностью реализуется в СУБД Access. Все современные тенденции — по созданию Web-страниц доступа к данным, многопользовательского режима работы, поддержание технологии клиент-сервер, интеграции с другими приложениями, даже средства разработки проектов, которые являются клиентскими приложениями Microsoft SQL Server — всеми этими возможностями обладает СУБД Access.

Схема данных будет полностью соответствовать логической модели данных (см. рис.5), но создана она будет в Microsoft Access 2009.

Рисунок 5 — Физическая модель данных.