В. П. Информационные системы в технике и технологиях. Ч. Диплом

Вид материала

Диплом

Содержание Вариант использования Практические рекомендации по применению расширения Видимость атрибутов (visibility) Общий синтаксис записи атрибута: строка текста Общий синтаксис записи операции Тело метода Ассоциация (assosiation) Работает в 1.. Композиция (composition) Обобщение (generalization) Диаграмма состояний (statechart diagram) Переход (transition) Действие (action) Деятельность (activity) Диаграмма деятельности (activity diagram) 2 Разработка информационной системы Методология Гейна и Сарсона. Методология SADT. Методология UML. 2.2 Программное обеспечение ... Полное содержание

Подобный материал:

• Зудилин Александр Эдуардович, ст преподаватель рабочая программа, 65.76kb.
• Давыдов Анатолий Васильевич, проф., доктор геолого минералогических наук рабочая программа, 203.01kb.
• Голиков Юрий Владимирович, проф., доктор геолого-минералогических наук рабочая программа, 68.4kb.
• Силина Тамара Сергеевна, ст преподаватель кафедры геоинформатики рабочая учебная программа, 108.81kb.
• Шилина Галина Васильевна, доцент, кандидат геолого-минералогических наук рабочая программа, 74.64kb.
• Шилина Галина Васильевна, доцент, кандидат геолого-минералогических наук рабочая программа, 76.17kb.
• Шилина Галина Васильевна, доцент, кандидат геолого-минералогических наук рабочая программа, 60.7kb.
• Рабочая программа учебной дисциплины сд. 07 Проектирование ис для специальности (направления), 172.73kb.
• Рабочая программа учебной дисциплины сд. 02 Корпоративные ис для специальности (направления), 158.22kb.
• Рабочая программа учебной дисциплины дс. 01 Банковские ис для специальности (направления), 184.59kb.

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

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

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

В языке имеется 4 вида графических конструкций:

• значки (пиктограммы);
  
• графические символы на плоскости;
  
• пути (линии);
  
• строки текста.
  

Диаграммой самого верхнего уровня считается предложенная А. Якобсоном в OOSE диаграмма вариантов использования системы в целом. Именно она является исходным концептуальным представлением системы и строится с целью:

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

Точка зрения модели: внешний пользователь системы. В диаграмму вариантов использования входят актанты (actors), варианты использования (use case) и ассоциации (association).

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

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

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

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

Вариант использования (use case) – абстрактное описание класса сервиса (сервисных функций), предоставляемого актанту в ответ на его запросы.

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

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

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

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

Например, отношение расширения (extend) - один из видов зависимости.

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

Практические рекомендации по применению расширения

1. Зафиксировать в начале обычный, “нормальный” вариант использования
   
2. Анализировать каждый шаг этого варианта идти и задавать вопрос “Что в этом варианте может идти не так? Как иначе можно выполнить этот шаг?”
   
3. Определить все отклонения как расширения данного варианта использования. Количество таких расширений может быть довольно большим, но их отделение способствует лучшему пониманию проблемы.
   

Диаграмма вариантов использования дополняется сценариями. Сценарий – текстовая запись последовательности действий, выполняемых актантами и системой, на естественном языке. Каждый вариант использования имеет свой сценарий, в котором вначале излагается основная (нормальная) последовательность, а затем – все альтернативы (ошибочные действия и другие варианты). Пример оформления сценария приведен в [22 ].

Второй важнейшей диаграммой концептуального уровня в UML является диаграмма классов, использующая фундаментальное для ООП понятие класса.

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

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

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

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

Класс имеет имя, список операций, методов и атрибутов.

Операция (operation) – спецификация (описание) результата преобразования или запроса, которые должен выполнить вызываемый объект. Имеет имя и список параметров.

Метод (method) – процедура, непосредственно реализующая операцию; у нее есть алгоритм и описание процедуры.

Другой способ реализации операций: событие вызова, переводящее активный объект в другое состояние. Используется при реализации диаграмм состояний (statechart diagram), построенных на основе теории конечных автоматов. Операция может быть абстрактной, то есть не иметь определенного способа реализации, для нее нельзя определить ни метод, ни событие вызова. Атрибуты класса (class attributes) (свойства, properties) – свойства или характеристики данного класса, которые могут принимать только одно значение из некоторого множества значений определенного типа. Совокупность конкретных значений атрибутов определяет – объект или абстракцию: класс – потомок. Атрибуты находятся в отношении ассоциации с основным классом, которая всегда подразумевается, но в явном виде не изображается на диаграмме. Порядок инициализации разных атрибутов в классе языком UML не оговаривается, то есть считается произвольным.

Классы делятся по категориям – стереотипам. Различают сущностные (entity), граничные (интерфейсные) (boundary, interface), управляющие (control) и логические (logical) классы. Сущностные классы соответствуют длительно хранимым структурам данных (таблицам, файлам и т.д.). Поэтому диаграмма сущностных классов фактически является аналогом ER-модели на разных уровнях представления. Граничные классы являются визуальными (формы, меню, поля ввода/вывода и т.д.) и задают возможные интерфейсы системы с актантами. Управляющие классы отвечают за управление процессами и реализацию алгоритмов обработки сообщений. Сложные алгоритмы вычислений и обработки , реализуемые отдельными процедурами и программными модулями, представляются в модели логическими классами. Как правило, каждый вариант использования должен включать в себя не менее одного управляющего и одного граничного класса. Однако отдельные классы могут обслуживать (реализовывать) несколько вариантов использования. Примеры диаграмм классов разных уровней представления можно найти в [18,19,21-26].

. Видимость атрибутов (visibility) (область видимости) классов:

• + public (открытый, общедоступный) – атрибут доступен или виден из любого другого класса пакета, в котором определена диаграмма;
  
• # protected (защищённый) – атрибут не доступен или не виден для всех классов, за исключением подклассов данного класса;
  
• - private (закрытый) – атрибут не доступен или не виден для всех других классов без исключения, он доступен и виден только внутри данного класса. Потомкам класса (подклассам) он не доступен.
  

Общий синтаксис записи атрибута: строка текста

<стереотип> <видимость> <имя><множество>: тип = <исходное значение> {строка свойств}.

Операция (operation) – спецификация преобразования или запроса, который должен выполнить вызываемый объект. Имеет имя и список параметров.

Операция реализуется методом (method). У метода есть алгоритм и описание процедуры или событие вызова (call event).

Общий синтаксис записи операции:

<стереотип> <видимость> имя (<список параметров>): <возвращаемый тип> {строка свойств}.

Метод объявляется так же, как операция. Если операция абстрактна, то ставится Abstract или имя пишется курсивом, метода она не имеет.

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

Классы могут находиться между собой в различных отношениях (связях). Базовыми отношениями являются:

• отношения зависимости (dependency relationship);
  
• отношения ассоциации (association relationship);
  
• отношения обобщения (generalization relationship);
  
• отношения реализации (realization relationship).
  

В зависимость включаются все виды связей, кроме ассоциаций, обобщений и реализаций. Зависимость может иметь имя, но часто его не ставят, так как из контекста ясна её семантика.

Ассоциация (assosiation) – в отличие от зависимости, которая относится к классу в целом, задает связи между объектами. Кроме того, в ассоциации проставляется множественность участия экземпляров в связи и обязательность.

Обозначение “*” обозначает “0. .*”, т.е. необязательность связи.



Работает в 1..*


1
1..*


Важным частным случаем ассоциации является агрегация.

Агрегация (Aggregation) – один из классов (агрегат) состоит из (включает в себя, характеризуется) других классов. (отношение часть/ целое (Part of)). Это отношение является фундаментальным при моделировании сложной системы, позволяет декомпозировать систему на составные части. В агрегации принцип наследования не соблюдается. Каждая часть обладает своими атрибутами и поведением.

Частным случаем агрегации является композиция.

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

Единственное ограничение, которое вносит агрегация в ассоциации – отсутствие цикличности связи, так как. класс не может содержаться сам в себе.

Обобщение (generalization) – обычное таксономическое отношение между родите-лем (предком) и частными примерами (дочерьми, детьми, сыновьями, потомками). Реализация – это отношение между спецификацией и программной реализацией. При этом считается, что в модели есть элементы, определяющие поведение, а также реализацию этого поведения. Есть много способов реализации одной и той же спецификации, одна реализация может относиться к нескольким спецификациям, т.е. это отношение M: N.

Тот, кто реализует, называется клиентом, носитель спецификации – источник (поставщик). Так как классы могут содержать полную информацию о реализации (атрибуты, типы), для спецификации введён ещё один особый класс – «интерфейс», который определяет спецификацию и не содержит деталей реализации. Таким образом, источниками реализаций в UML являются варианты использования, обычные классы с неполной информацией и специальные классы – интерфейсы.

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

Диаграмма классов во многом определяет реализацию системы. На концептуальном и логическом уровнях следует использовать русские имена. На физическом уровне (в разделе2 дипломного проекта) осуществляется переход на английские имена с использованием рекомендаций по транскрипции и трансляции русских букв латинскими буквами (Ц – ts, Ж – zh, Ы – y и т.д.).

Диаграмма состояний (statechart diagram) – диаграмма, на которой изображается конечный автомат с простыми состояниями, переходами, вложенными композитными состояниями.

В отличие от статического представления диаграмма состояний является детализацией диаграммы вариантов использования, на логическом уровне она описывает поведение объектов системы и системы в целом. Поскольку речь идёт о состояниях объектов – экземпляров классов, то предварительно должны быть определены классы объектов на логическом уровне, т.е. должна быть построена диаграмма классов. В основе диаграммы лежит понятие конечного автомата (state machine).

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

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

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

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

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

В каждый момент времени автомат может находиться только в одном из состояний (последовательное поведение). Для моделирования параллельного поведения в одной модели рассматриваются несколько отдельных автоматов.

Исключение конфликтов при переходах достигается введением сторожевых условий.

Имя состояния рекомендуется выражать глаголом в настоящем времени (звонит, печатает) – что делает объект? или причастием (занят, свободен, передано, получено) – результат действия. Все состояния, даже анонимные (без имени), должны быть различными. Дублирование состояний на диаграмме не допускается.

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

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

Типичными атомарными действиями являются присваивания значений атрибутам, доступ к значениям атрибутов или связей, простые вычисления, отправка сигналов другим объектам. Запуск действий производится переходами. Различают входное событие перехода (поглощение) – автомат устанавливается в определённое состояние и выходное событие перехода – автомат теряет это состояние. Соответственно различают входное(entry) и выходное(exit) действия. Каждое действие описывается отдельной строкой в формате <метка действия ”/” выражение действия>.

Деятельность (activity) –набор действий, имеет внутреннюю структуру и может быть прервана переходом по внешнему событию (переключающему). Оно выполняется в течение конечного времени и поэтому не может быть приписано переходу, а только состоянию в целом. Внутри состояния деятельность соответствует вызову какой-либо процедуры или метода и обозначается do./ <выражение деятельности>

Для обозначения выражения действия в UML нет строго определённой нотации. Предполагается, что для этого будет применяться какой-либо язык программирования. Можно использовать формальный язык описания ограничений Object Constraint Language (OCL), который фактически является частью языка UML.

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

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

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

Выражение действия, связанное с переходом, (action expression), всегда выполняется, если переход состоялся («сработал») до начала выполнения каких-либо действий в целевом состоянии.

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

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

Диаграмма деятельности (activity diagram) – частный случай диаграммы состояний, в которой все или большая часть состояний является состояниями деятельности или состояниями действия и в которых все или большая часть переходов запускаются при завершении деятельности в исходных состояниях.

Эта диаграмма соответствует традиционной схеме алгоритма или программы, поэтому является важным дополнительным средством описания логики процессов.

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

Конечная диаграмма деятельности должна иметь единственное начальное и единственное конечное состояние. Рисуется она сверху вниз.

В диаграммах деятельности используются только нетриггерные переходы, т. е. неявно предполагается, что переход возможен только по завершении внутренней деятельности. В связи с этим переключающие события на диаграмме деятельности не помечаются и могут помечаться только сторожевые условия. Кроме того, с переходом не связывается каких-либо дополнительных действий. Ветвление, т. е. переход в несколько состояний, обозначается ромбом без текста. С каждым переходом из ромба связывается сторожевое условие. Входящая в ромб стрелка – только одна, исходящих может быть несколько со сторожевыми условиями. Горизонтальная черта на диаграммах называется линейкой синхронизации. Часто необходимо выделять группы действий, выполняемых отдельными объектами. Это делается разделением диаграммы деятельности на вертикальные полосы, называемые “плавательными дорожками” (swim lines). Например, можно выделить деятельности определенных подразделений.

Примеры оформления диаграмм деятельностей (активностей ) можно найти в [18,19,21-26].Состав и количество разрабатываемых в информационно-логической модели диаграмм состояний и деятельностей согласовываются с руководителем дипломного проекта. Диаграмма деятельности может строиться для отдельного класса, варианта использования, отдельной операции класса или подсистемы (системы).

Таким образом, полностью проработанная информационно-логическая модель в методологии UML включает в себя:

• модель вариантов использования (диаграмма вариантов использования и сценарии);
  
• модель анализа (диаграммы классов анализа, диаграммы состояний и деятельностей).
  

2 РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ


2.1 Информационное обеспечение


Конструкторская проработка информационного обеспечения ИС по построенной в предыдущей главе информационно-логической модели должно соответствовать требованиям государственных стандартов ИТ, ЕСКД, ЕСПД и выбранной методологии проектирования.

По ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем» в составе информационного обеспечения проекта предусматриваются следующие виды документов:

• Перечень входных сигналов и данных (В1).
  
• Перечень выходных сигналов (документов) (В2).
  
• Описание информационного обеспечения системы (П5).
  
• Описание организации информационной базы (П6).
  
• Описание систем классификации и кодирования (П7).
  
• Описание массива информации (П8).
  
• Чертежи форм документов (видеокадров) (С9).
  
• Ведомость машинных носителей информации (ВМ, по ЕСКД).
  

• Массив входных данных (В6).
  
• Каталог базы данных (В7).
  
• Состав выходных данных (сообщений) (В8).
  
• Инструкция по формированию и ведению базы данных (набора данных) (ИО).
  

Последние 5 видов документов входят в состав эксплуатационной документа-ции.

Содержание и правила оформления документов оговорены руководящим документом РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов», раздел 5.

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

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

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

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

В разделе «Организация ведения информационной базы » приводят последовательность процедур при создании и обслуживании базы с указанием, при необходимости, регламента выполнения процедур и средств защиты базы от разрушения и несанкционированного доступа. Особо следует выделить роль администратора базы данных при работе с нормативно-справочной информацией (НСИ). Должна быть приведена последовательность процедур по маршруту движения групп документов и регламент работы с выходными документами.

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

1. правила подготовки данных;
   
2. порядок и средства заполнения базы данных;
   
3. процедуры изменения и контроля базы данных;
   
4. порядок и средства восстановления базы данных.
   

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

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

Методология Гейна и Сарсона. Исходными данными являются подробные структурограммы накопителей, полученные после перехода от ER или SHM-модели к реляционной модели с учетом нормализации и приведения, как минимум, к 2НФ. Переход на физический уровень соответствует использованию латиницы в обозначениях полей и таблиц с учетом типов данных используемой СУБД. При использовании файловой системы должна быть подробно раскрыта структура файлов и определены методы доступа к структурным единицам хранения. В описании логики процессов просмотра и редактирования таблиц базы данных должны быть предусмотрены меры по контролю за целостностью базы данных.

Методология SADT. Исходными данными являются диаграммы активностей ведения базы данных и ER-диаграммы, построенные в инструментальных средах AllFusion Modeling Suite (BPwin, ERwin ) или аналогичных. Переход на физический уровень представления реляционной модели обеспечивает необходимую информацию для разработки конструкторской документации. При этом рекомендуется воспользоваться мощными средствами генерации отчетов , имеющимися в инструментальных средах, а также средствами автоматической генерации структур таблиц базы данных в формате целевой СУБД.

Методология UML. Исходными данными являются диаграммы сущностных классов моделей анализа и проектирования. Они должны быть переведены на физический уровень реализации с указанием полных спецификаций атрибутов и методов доступа и выборки данных в целевой СУБД. При использовании инструмен-тальной системы Rational Rose 2001a или более поздних версий рекомендуется построить модель данных с помощью встроенного средства Data Modeler, по своим функциям аналогичного Erwin. В системе также имеются мощные средства генерации отчетов и автоматической генерации структур таблиц базы на одну из выбранных целевых СУБД. Так как основой методологии является объектно-ориентированная ориентация, то возможно использование объектно-ориентированных СУБД новых поколений, например, Cache и др.


2.2 Программное обеспечение

Конструкторская проработка программного обеспечения ИС по построенной в предыдущей главе информационно-логической модели также должна соответствовать требованиям государственных стандартов ИТ, ЕСКД, ЕСПД и выбранной методологии проектирования.

По ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем» для эксплуатации программного обеспечения ИС предусматриваются следующие виды документов:

• описание программного обеспечения (ПА);
  
• описание алгоритмов (ПБ)
  
• программная документация, оговоренная в ЕСПД.
  

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

1. структура программного обеспечения;
   
2. функции частей программного обеспечения
   
3. методы и средства разработки программного обеспечения;
   
4. операционная система;
   
5. средства, расширяющие возможности операционной системы.
   

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

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

Программная документация по ЕСПД по согласованию с руководителем проекта может содержать руководства оператора, программиста, системного программиста. Однако обязательными являются документы: описание применения , программа и методика испытаний, описание контрольного примера. Эти документы должны быть разработаны в полном соответствии с ГОСТом как по форме, так и по содержанию.

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

Методология Гейна и Сарсона. Исходными данными для разработки являются диаграммы потоков данных, структурограммы и описания логики процессов в проектируемой системе. В зависимости от используемых архитектуры ИС, операцион-ной системы, среды программирования и СУБД (их выбор должен быть обоснован по техническим, экономическим и эргономическим критериям) производится разработка структуры программного обеспечения, осуществляется разделение на подсистемы, комплексы и программные модули. Описываются и обосновываются решения по интерфейсу . Реализация ведется в современных объектно-ориентированных средах и системах программирования (Delphi, C++, Java, Visual Basic и др.)

Методология SADT. Исходными данными для разработки является набор диаграмм активностей и модель данных, построенная средствами AllFusion Modeling Suite (BPwin, ERwin ) или аналогичных. После перехода в модели данных на физический уровень и полного определения структуры базы данных и архитектуры системы производится реализация работ, намеченных в диаграммах активностей , в той или иной современной среде программирования с максимальным использованием библиотек готовых программных элементов и COM-технологий. Описываются и обосновываются решения по инерфейсу.

Методология UML. Данная методология более глубоко, чем предыдущие, поддерживает этап разработки программного обеспечения на физическом уровне. Это связано с тесной интеграцией с современными объектно-ориентированными системами программирования.. В инструментальную среду Rational Rose и другие, поддерживающие UML, встроены механизмы кодогенерации структуры программного обеспечения в выбранной среде программирования и включения готовых библиотечных модулей. Обеспечен переход из модели (проекта) в среду программирования и обратно. Все изменения в проекте автоматически отслеживаются и в реализации. Конечно, остается еще много ручной работы по написанию оригинальных методов и процедур, но в целом процесс разработки и сопровождения системы существенно облегчается.

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

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

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

Диаграмма последовательности (sequence diagram) отображает последователь-ность и время обмена сообщениями объектов между собой (взаимодействие по управлению). Если сообщение - вызов процедуры, то отправитель блокируется, пока вызывающая процедура не завершится и не вернёт управление. Сообщениями могут быть вызовы операции, возврат значений, создание и уничтожение объектов, посылка сигнала. Диаграмма последовательности – единственная диаграмма , на которой в явном виде есть ось времени ( она направлена сверху вниз). Диаграмма последовательности показывает взаимодействие объектов и строится для объектов.

Диаграмма кооперации ( collaboration diagram ) –диаграмма, на которой показано взаимодействие объектов между собой ( кооперация ) для решения некоторой фундаментальной задачи.

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

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

Активный объект не существует в рамках другого объекта. Он может быть вызван в результате деятельности какого-либо объекта, но после этого становится совершенно независимым. Управляется активный объект событиями вызова. Пассивный объект своего собственного потока управления не имеет, однако, свое адресное пространство у него есть, его операции вызываются активным объектом. Активность или пассивность объектов определяет разработчик. На диаграммах активные объекты выделяются жирными линиями или словом «active».

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

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

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


Диаграмма компонентов ( Component diagram ) - это диаграмма, на которой изображены организация типов компонентов и зависимость между ними.
Компонент – часть физической реализации системы, обеспечивает функционирование ряда интерфейсов. Это – программный код ( исходный, бинарный, выполнимый ) или его эквиваленты – сценарии и командные файлы, некоторые физические блоки, которые могут соединять с другими компонентами, заменять, перемещать, архивировать и т. д. Графически компонент изображается прямоугольником со вставленными двумя более мелкими прямоугольниками. Внутри – имя компонента и некоторая дополнительная информация.

Исторически малые прямоугольники обозначали данные и операции ( атрибуты ) кода реализации. В UML в них ничего не заносят.

Компонент может быть представлен на уровне типа или на уровне экземпляра. Имя типа пишется с большой буквы. Общая нотация: ‹ имя компонента › «:» ‹ имя типа ›. Вся строка подчеркивается или выделяется жирным шрифтом. Используются имена и стандартные расширения файлов (exe, dll, html, txt, doc, dbf и т.д.)

Интерфейс ( interface ) – именованное множество операций, описывающее поведение элемента. Это – дескриптор для видимых операций класса, компонента или другого элемента ( например, пакета ), не раскрывающий внутреннюю структуру. Он может описывать только часть операций класса. Класс может поддерживать несколько интерфейсов, как независимых, так и пересекающихся по операциям.

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

В модели развертывания строится диаграмма развертывания.

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

До построения диаграммы компонентов принимаются решения по среде реализации, ОС и СУБД.

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

Особо включается БД в виде таблиц ( для реляционной модели ) и их взаимосвязи.

Обычно диаграмма компонентов разрабатывается вместе с диаграммой развертывания.

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

Примеры оформления диаграмм можно найти в [ 8,9,11-16].

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


2.3. Оценка характеристик проектируемой системы

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

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

Для расчета необходимой внешней памяти воспользуемся формулой (1):

, Мбайт (1)

где V_ВП – общий объем внешней памяти;

V_ОС – объем внешней памяти, требуемый для хранения файлов операционной системы и ее нормальной работы;

V_СУБД – объем внешней памяти, требуемый для хранения файлов

СУБД;

V_данных – объем внешней памяти, требуемый для хранения записей базы данных и результатов выполнения функций;

V_{программы} – объем внешней памяти, необходимой для хранения

текстов и библиотек приложений.

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

В качестве примера рассмотрим расчет требуемых ресурсов памяти для АС учета единиц складского хранения, работающей под управлением операционной системы Microsoft Windows 98 c использованием СУБД Visual FoxPro 6.0.

По экспериментальным данным Windows 98 требует V_ОС = 166 Мбайт. Объем памяти, необходимый для Visual FoxPro 6.0, составляет примерно 60 Мбайт. Для расчета объема хранимых данных предположим наихудший случай: максимальное заполнение базы данных на 1 миллион единиц хранения. Данные расчетов сведены в таблицу 4. Индексный файл ориентировочно принят в размере 15% от основного.

Итак, мы получили, что V_данных = 1590.75 Мбайт (следует учесть, что 1Кбайт=1024 байт, а 1Мбайт=1024 Кбайт, таким образом, 1Мбайт=1024*1024=1048576 байт ). Объем памяти, требуемый для программы приложения, составляет 8 Мбайт.

Сложив полученные данные, будем иметь:

V_ВП  1600 Мбайт = 1,6 Гбайт.

Наиболее распространены устройства внешней памяти типа «винчестер»емкостью от 3,2 Гбайт до 250 Гбайт, причем материнская плата позволяет подключать несколько ( обычно до 4-х) устройств. Таким образом, даже минимальная конфигурация ЭВМ будет обеспечивать требуемые ресурсы долговременной памяти .

Теперь рассчитаем объем оперативной памяти.

По экспериментальным данным и данным разработчиков имеем следующие требования к оперативной памяти:

V_ОС = 32 Мбайт; V_СУБД = 8 Мбай; V_{программы} = 4 Мбайт.

Результаты расчета объема кэша для хранения данных в оперативной памяти приведены в таблице 5.

Таким образом, V_данных = 7,68 Мбайт.

Подсчитаем общий объем оперативной памяти:

V_ОЗУ = 32+8+4+7.68 = 51.68 Мбайт.

Следовательно, объем оперативной памяти, необходимый для нормального функционирования программы:

V_ОЗУ = 52 Мбайт.

Оперативная память комплектуется модулями стандартного размера. В настоящее время получили распространение модули 32, 64, 128, 256, 512 Мбайт, которые можно в зависимости от типа материнской платы собирать в наборы, обеспечивая, тем самым, необходимый объем памяти. Каждая материнская плата имеет ограничения как по количеству разъемов подключения, так и по общему объему оперативной памяти, что следует учитывать при выборе процессорного блока компьютера. Окончательно выбираем объем ОЗУ 64 Мбайт.

Расчетные таблицы удобно обрабатывать как электронные таблицы Excel, входящие в пакет Microsoft Office. Поскольку оценивается лишь порядок величин, округление результата производится с точностью до мегабайта. Для распределенных систем с архитектурой «клиент-сервер» необходимо также оценить объем требуемой внешней и оперативной памяти на сервере. При использовании операционной системы Microsoft Windows 2000 Advanced Server потребуется примерно 1400 Мбайт внешней памяти. Кроме того, для обеспечения взаимодействия с клиентским слоем потребуется не менее 20 Мбайт для обеспечения функционирования утилиты ADO . При расчете внешней памяти под данные следует учесть, что, кроме хранения индексных файлов и файлов данных , во внешней памяти сервера необходимо хранить журнал транзакций, который по своему объему иногда превосходит файл данных. Для оценки объема журнала транзакций следует задаться максимальной интенсивностью потока транзакций и периодом его хранения.

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

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

Общее время реакции системы на выполнение запроса рассчитывается по формулам (2):

Таблица 2.2 - Расчет объема данных

Таблица 2.3 - Расчет объема буферизации



(2)

В формулах (2) t_ввода - время на ввод входных данных запроса;

k_вв – коэффициент ошибок при вводе, для расчетов можно принять равным 1.5;

L_симв – количество символов, вводимых в качестве исходных данных запроса;

t_симв – время ввода одного символа , при ручном вводе с клавиатуры в некоторую экранную форму можно принять в среднем равным 2 с;

t_{считывания} – время, затрачиваемое на считывание физических блоков при работе с накопителем;

N_бл – количество считываемых физических блоков, зависит от

количества обрабатываемых таблиц (файлов) и объема таблиц

(файлов);

t_поз – время позиционирования головок дискового накопителя ;

t_сч.бл. – время считывания физического блока в дисковом накопите-

ле;

t_{вычислений} – время, затрачивамое процессором на обработку инфор- мации с учетом выполнения циклов;

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

K₁ – среднее количество тактов машинных команд на одну операцию, для большинства случаев можно принять K₁=60;

 – тактовая частота процессора, Гц;

V_табл – средний объем таблицы, байт;

N_табл – количество таблиц, обрабатываемых в запросе;

V_блока – объем физического блока носителя, байт;

t_вывода – время на вывод результата на устройство вывода или

отображения, для принтера оценивается отдельно. Для дисплея можно принять 0.5 с (зависит от типа видеокарты и дисплея).

Оценим время реакции той же системы учета единиц складского хранения.

Для расчета возьмем случай создания наиболее сложного ежемесячного отчета. Запрос требует ввода примерно 20 символов, что займет 40 cекунд времени. В запросе происходит поиск записей по трем таблицам, общим объемом 6882000 байт. В среднем просматривается половина записей.

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



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

Теперь подсчитаем время печати по формуле:

t_{печати =} t_{печати страницы} *N, (9)

где N — количество страниц отчета.

Согласно формуле (9) для струйного принтера с временем печати 0,4 минуты на страницу формата А4 при N=10:

t_печати = 0,4*10 = 4 минуты.

Полное время реакции системы при формировании самого сложного отчета с печатью на струйном принтере 7 минут.

Итак, согласно проведенным расчетам можно сделать вывод о технических требованиях, предъявляемых системой: процессор класса Pentium с тактовой частотой 200 МГц и выше, объем оперативного запоминающего устройства (ОЗУ) 64 Мбайт, жесткий диск типа «винчестер» емкостью не менее 1,7 Гбайт (стандартные значения поставляемых компонент).


БИБЛИОГРАФИЧЕСКИЙ СПИСОК