Внутримашинное информационное обеспечение включает макеты (экранные формы) для ввода первичных данных в ЭВМ или вывода результатной информации, и структуры информационной базы: входных, выходных файлов, базы данных.
ПРОЕКТИРОВАНИЕ ЭКРАННЫХ ФОРМ ЭЛЕКТРОННЫХ ДОКУМЕНТОВ
Под электронными формами документов понимается не изображение бумажного документа, а изначально электронная (безбумажная) технология работы; она предполагает появление бумажной формы только в качестве твердой копии документа.
Электронная форма документа (ЭД) — это страница с пустыми полями, оставленными для заполнения пользователем. Формы могут допускать различный тип входной информации и содержать командные кнопки, переключатели, выпадающие меню или списки для выбора.
Создание форм электронных документов требует использования специального программного обеспечения. На рисунке А.11.8 приведены основные типовые элементы электронного документа, использование которых предусмотрено в большинстве программ автоматизации проектирования электронных документов.
Рисунок А.11.8 - Элементы электронного документа
К недостаткам электронных документов можно отнести неполную юридическую проработку процесса их утверждения или подписания.
Технология обработки электронных документов требует использования специализированного программного обеспечения — программ управления документооборотом, которые зачастую встраиваются в корпоративные ИС.
Проектирование форм электронных документов (ЭД), т.е. создание шаблона формы с помощью программного обеспечения проектирования форм, обычно включает в себя выполнение следующих шагов:
1) создание структуры ЭД — подготовка внешнего вида с помощью графических средств проектирования;
2) определение содержания формы ЭД, т.е. выбор способов, которыми будут заполняться поля. Поля могут быть заполнены вручную или посредством выбора значений из какого-либо списка, меню, базы данных;
3) определения перечня макетов экранных форм — по каждой задаче проектировщик анализирует "постановку" каждой задачи, в которой приводятся перечни используемых входных документов с оперативной и постоянной информацией и документов с результатной информацией;
4) определение содержания макетов — выполняется на основе анализа состава реквизитов первичных документов с постоянной и оперативной информацией и результатных документов.
Работа заканчивается программированием разработанных макетов экранных форм и их апробацией.
ИНФОРМАЦИОННАЯ БАЗА И СПОСОБЫ ЕЕ ОРГАНИЗАЦИИ
Основной частью внутримашинного информационного обеспечения является информационная база. Информационная база (ИБ) — это совокупность данных, организованная определенным способом и хранимая в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач.
Все файлы ИБ можно классифицировать по следующим признакам:
- по этапам обработки (входные, базовые, результатные);
- по типу носителя (на промежуточных носителях — гибких магнитных дисках, устройствах с флэш памятью и на основных носителях — жестких магнитных дисках, магнитооптических дисках и др.);
- по составу информации (файлы с оперативной информацией и файлы с постоянной информацией);
- по назначению (по типу функциональных подсистем);
- по типу логической организации (файлы с линейной и иерархической структурой записи, реляционные, табличные);
- по способу физической организации (файлы с последовательным, индексным и прямым способом доступа).
Входные файлы создаются с первичных документов для ввода данных или обновления базовых файлов.
Файлы с результатной информацией предназначаются для вывода ее на печать или передачи по каналам связи и не подлежат долговременному хранению.
К числу базовых файлов, хранящихся в информационной базе, относят:
- основные;
- рабочие;
- промежуточные;
- служебные;
- архивные файлы.
Основные файлы должны иметь однородную структуру записей и могут содержать записи с оперативной и условно-постоянной информацией. Оперативные файлы могут создаваться на базе одного или нескольких входных файлов и отражать информацию одного или нескольких первичных документов. Файлы с условно-постоянной информацией могут содержать справочную, расценочную, табличную и другие виды информации, изменяющейся в течение года не более чем на 40%, а следовательно, имеющие коэффициент стабильности не менее 0,6.
Файлы со справочной информацией должны отражать все характеристики элементов материального производства (материалы, сырье, основные фонды, трудовые ресурсы и т.п.). Как правило, справочники содержат информацию классификаторов и дополнительные сведения об элементах материальной сферы, например о ценах. Нормативно-расценочные файлы должны содержать данные о нормах расхода и расценках на выполнение операций и услуг. Табличные файлы содержат сведения об экономических показателях, считающихся постоянными в течение длительного времени (например, процент удержания, отчисления и пр.). Плановые файлы содержат плановые показатели, хранящиеся весь плановый период.
Рабочие файлы создаются для решения конкретных задач на базе основных файлов путем выборки части информации из нескольких основных файлов с целью сокращения времени обработки данных.
Промежуточные файлы отличаются от рабочих файлов тем, что они образуются в результате решения экономических задач, подвергаются хранению с целью дальнейшего использования для решения других задач. Эти файлы, так же как и рабочие файлы, при высокой частоте обращений могут быть также переведены в категорию основных файлов.
Служебные файлы предназначаются для ускорения поиска информации в основных файлах и включают в себя справочники, индексные файлы и каталоги.
Архивные файлы содержат ретроспективные данные из основных файлов, которые используются для решения аналитических, например прогнозных, задач. Архивные данные могут также использоваться для восстановления информационной базы при разрушениях.
Организация хранения файлов в информационной базе должна отвечать следующим требованиям:
- полнота хранимой информации для выполнения всех функций управления и решения экономических задач;
- целостность хранимой информации, т. е. обеспечение непротиворечивости данных при вводе информации в ИБ;
- своевременность и одновременность обновления данных во всех копиях данных;
- гибкость системы, т.е. адаптируемость ИБ к изменяющимся информационным потребностям;
- реализуемость системы, обеспечивающая требуемую степень сложности структуры ИБ;
- релевантность ИБ, под которой подразумевается способность системы осуществлять поиск и выдавать информацию, точно соответствующую запросам пользователей;
- удобство языкового интерфейса, позволяющее быстро формулировать запрос к ИБ;
- разграничение прав доступа, т.е. определение для каждого пользователя доступных типов записей, полей, файлов и видов операций над ними.
Существуют следующие способы организации ИБ:
- совокупность локальных файлов, поддерживаемых функциональными пакетами прикладных программ,
- интегрированная база данных, основывающаяся на использовании универсальных программных средств загрузки, хранения, поиска и ведения данных, т.е. системы управления базами данных (СУБД).
Локальные файлы вследствие специализации структуры данных под задачи обеспечивают, как правило, более быстрое время обработки данных. Однако недостатки организации локальных файлов, связанные с большим дублированием данных в информационной системе и, как следствие, несогласованностью данных в разных приложениях, а также негибкостью доступа к информации, перекрывают указанные преимущества. Поэтому организация локальных файлов может применяться только в специализированных приложениях, требующих очень высокой скорости реакции при импорте необходимых данных.
Интегрированная ИБ, т.е. база данных (БД) — это совокупность взаимосвязанных, хранящихся вместе данных при такой минимальной избыточности, которая допускает их использование оптимальным образом для множества приложений.
Централизация управления данными с помощью СУБД обеспечивает совместимость этих данных, уменьшение синтаксической и семантической избыточности, соответствие данных реальному состоянию объекта, разделение хранения данных между пользователями и возможность подключения новых пользователей. Но централизация управления и интеграция данных приводят к проблемам другого характера: необходимости усиления контроля вводимых данных, необходимости обеспечения соглашения между пользователями по поводу состава и структуры данных, разграничения доступа и секретности данных.
Основными способами организации БД являются создание централизованных и распределенных БД. Основным критерием выбора способа организации ИБ является достижение минимальных трудовых и стоимостных затрат на проектирование структуры ИБ, программного обеспечения системы ведения файлов, а также на перепроектирование ИБ при возникновении новых задач.
ДИАГРАММЫ КЛАССОВ
Диаграммы классов при моделировании объектно-ориентированных систем встречаются чаще других. На таких диаграммах показывается множество классов, интерфейсов, коопераций и отношений между ними.
Диаграммы классов используются для моделирования статического вида системы с точки зрения проектирования. Сюда по большей части относится моделирование словаря системы, коопераций и схем. Кроме того, диаграммы классов составляют основу еще двух диаграмм - компонентов и развертывания.
Диаграммы классов важны не только для визуализации, специфицирования и документирования структурных моделей, но также для прямого и обратного проектирования исполняемых систем.
Строя дом, вы начинаете со словаря, включающего его основные строительные блоки: стены, потолки, окна, двери, полы, стропила. Хотя все эти сущности носят преимущественно структурный характер (например, стена характеризуется высотой, шириной и толщиной), они имеют еще и поведенческие особенности (скажем, стены могут выдерживать определенную нагрузку, двери - открываться и закрываться; имеются ограничения на длину пролета без опор).
Структурные и поведенческие аспекты нельзя рассматривать изолированно. Напротив, при строительстве дома необходимо учитывать их взаимодействие. Процесс архитектурного проектирования состоит в том, чтобы, объединив все вышеупомянутые сущности, смоделировать красивое и непохожее на другие здание, способное удовлетворить все ваши функциональные и нефункциональные потребности. При этом чертежи, создаваемые для визуализации дома и специфицирования его деталей для подрядчика, представляют собой графическое изображение всех составляющих его элементов и их взаимодействие.
Создание программного обеспечения похоже на строительство дома. В UML диаграммы классов служат для визуализации статических аспектов этих строительных блоков и их отношений, а также для специфицирования деталей конструкции.
Диаграммой классов (Class diagram) называют диаграмму, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Ее изображают в виде множества вершин и дуг.
Рисунок А.11.9 - Диаграмма классов
Общие свойства. Диаграмме классов присущи общие для всех диаграмм свойства: имя и графическое содержание, являющееся одной из проекций модели. Вместе с тем диаграммы такого рода отличаются от остальных специфичным содержанием.
Диаграммы классов обычно содержат следующие сущности:
- классы;
- интерфейсы;
- кооперации;
- отношения зависимости, обобщения и ассоциации.
Подобно всем остальным диаграммам, они могут включать в себя примечания и ограничения.
Также в диаграммах классов могут присутствовать пакеты или подсистемы, применяемые для группирования элементов модели в более крупные блоки. Иногда в эти диаграммы помещают экземпляры, особенно если требуется визуализировать их тип (возможно, динамический).
На диаграммы классов похожи диаграммы компонентов и развертывания, но вместо классов они содержат соответственно компоненты и узлы.
ТИПИЧНЫЕ ПРИМЕРЫ ПРИМЕНЕНИЯ
Диаграммы классов применяют для моделирования статического вида системы с точки зрения проектирования. В этом представлении удобнее всего описывать функциональные требования к системе - услуги, которые она предоставляет конечному пользователю.
Обычно диаграммы классов используются в следующих целях:
- для моделирования словаря системы. Моделирование словаря системы предполагает принятие решения о том, какие абстракции являются частью системы, а какие - нет. С помощью диаграмм классов вы можете определить эти абстракции и их обязанности;
- для моделирования простых коопераций. Кооперация - это сообщество классов, интерфейсов и других элементов, работающих совместно для обеспечения некоторого кооперативного поведения, более значимого, чем сумма составляющих его элементов. Например, моделируя семантику транзакций в распределенной системе, вы не сможете понять происходящие процессы, глядя на один-единственный класс, поскольку соответствующая семантика обеспечивается несколькими совместно работающими классами. С помощью диаграмм классов удается визуализировать и специфицировать эти классы и отношения между ними;
- для моделирования логической схемы базы данных. Логическую схему можно представлять себе как чертеж концептуального проекта базы данных. Во многих сферах деятельности требуется хранить устойчивую (persistent) информацию в реляционной или объектно-ориентированной базе данных. Моделировать схемы также можно с помощью диаграмм классов.
КЛАССЫ
Класс - это абстракция сущностей, являющихся частью вашего словаря. Класс представляет не индивидуальный объект, а целую их совокупность.
Графическое изображение класса в UML показано на рисунке А.7. Такое обозначение позволяет визуализировать абстракцию независимо от конкретного языка программирования и подчеркнуть ее наиболее важные характеристики: имя, атрибуты и операции.
Рисунок А.11.10 – Пример класса в UML
Классом (Class) называется описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Графически класс изображается в виде прямоугольника.
Имена. У каждого класса должно быть имя, отличающее его от других классов. Имя класса - это текстовая строка. Взятое само по себе, оно называется простым именем; к составному имени спереди добавлено имя пакета, куда входит класс. Имя класса в объемлющем пакете должно быть уникальным. При графическом изображении класса показывается только его имя.
Имя класса может состоять из любого числа букв, цифр и ряда знаков препинания (за исключением таких, например, как двоеточие, которое применяется для отделения имени класса от имени объемлющего пакета). Имя может занимать несколько строк. На практике для именования класса используют одно или несколько коротких существительных, взятых из словаря моделируемой системы. Обычно каждое слово в имени класса пишется с заглавной буквы, например: Клиент, Успеваемость.
Атрибуты. Атрибут - это именованное свойство класса, включающее описание множества значений, которые могут принимать экземпляры этого свойства. Класс может иметь любое число атрибутов или не иметь их вовсе. Атрибут представляет некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Например, при моделировании клиентов можно задавать фамилию, адрес, номер телефона и дату рождения. В рассмотренном нами примере атрибуты – Ф.И.О. студента (тип: строка), дисциплина (тип: строка), оценка (тип: целое число). Таким образом, атрибут является абстракцией данных объекта или его состояния. В каждый момент времени любой атрибут объекта, принадлежащего данному классу, обладает вполне определенным значением.
Имя атрибута, как и имя класса, может быть произвольной текстовой строкой. На практике для именования атрибута используют одно или несколько коротких существительных, соответствующих некоторому свойству объемлющего класса.
Операции. Операцией называется реализация услуги, которую можно запросить у любого объекта класса для воздействия на поведение. Иными словами, операция - это абстракция того, что позволено делать с объектом. У всех объектов класса имеется общий набор операций. Класс может содержать любое число операций или не содержать их вовсе. Например, для всех объектов класса Rectangle(Прямоугольник) из библиотеки для работы с окнами, содержащейся в пакете языка Java, определены операции перемещения, изменения размера и опроса значений свойств. Часто (хотя не всегда) обращение к операции объекта изменяет его состояние или его данные. Операции класса изображаются в разделе, расположенном ниже раздела с атрибутами. При этом можно ограничиться только именами. Более детальная спецификация выполнения операции осуществляется с помощью примечаний и диаграмм деятельности.
Имя операции, как и имя класса, может быть произвольной текстовой строкой. На практике для именования операций используют короткий глагол или глагольный оборот, соответствующий определенному поведению объемлющего класса.
Операцию можно описать более подробно, указав ее сигнатуру, в которую входят имена и типы всех параметров, их значения, принятые по умолчанию, а применительно к функциям - тип возвращаемого значения. В рассмотренном нами примере процедуры – импортировать успеваемость, сформировать ведомость, построить график успеваемости, вывести задолженности; функция – получить оценку (возвращаемое значение имеет целочисленный тип).
При изображении класса необязательно сразу показывать все его атрибуты и операции. Как правило, это попросту невозможно - их чересчур много для одного рисунка, - да и не требуется (поскольку для данного представления системы лишь небольшое подмножество атрибутов и операций имеет значение). По этим причинам класс обычно сворачивают, то есть изображают лишь некоторые из имеющихся атрибутов и операций, а то и вовсе опускают их. Таким образом, пустой раздел в соответствующем месте прямоугольника может означать не отсутствие атрибутов или операций, а только то, что их не сочли нужным изобразить. Явным образом наличие дополнительных атрибутов или операций можно обозначить, поставив в конце списка многоточие.
Одна из деталей, наиболее существенных для атрибутов и операций классификаторов, - их видимость. Видимость свойства говорит о том, может ли оно использоваться другими классификаторами. Естественно, это подразумевает видимость самого классификатора. Один классификатор может "видеть" другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. В языке UML можно определить три уровня видимости:
- public(открытый) - любой внешний классификатор, который "видит" данный, может пользоваться его открытыми свойствами. Обозначается знаком + (плюс) перед именем атрибута или операции;
- protected(защищенный) - любой потомок данного классификатора может пользоваться его защищенными свойствами. Обозначается знаком # (диез);
- private(закрытый) - только данный классификатор может пользоваться закрытыми свойствами. Обозначается символом - (минус).
Всего существует четыре основных вида отношений между классами:
1) ассоциация (фиксирует структурные отношения — связи между экземплярами классов);
2) зависимость (отображает влияние одного класса на другой класс);
3) обобщение-специализация («is а»-отношение);
4) целое-часть, агрегация («part of»-отношение).
Зависимость. Зависимость — это отношение, которое показывает, что изменение в одном классе (независимом) может влиять на другой класс (зависимый), который использует его. Графически зависимость изображается как пунктирная стрелка, направленная на класс, от которого зависят. С помощью зависимости уточняют, какая абстракция является клиентом, а какая — поставщиком определенной услуги. Пунктирная стрелка зависимости направлена от клиента к поставщику.
Наиболее часто зависимости показывают, что один класс использует другой класс как аргумент в сигнатуре своей операции. Например, класс «ГрафикРазворота» появляется как аргумент в методах «Обрабатывать» и «Запланировано» класса «КонтроллерУгла». Поэтому, как показано на рисунке А.11.11, «КонтроллерУгла» зависит от класса «ГрафикРазворота».
Рисунок А.11.11 – Отношение зависимости
Агрегация. Связи обозначают равноправные (клиент-серверные) отношения между объектами. Агрегация обозначает отношения объектов в иерархии «целое/часть». Агрегация обеспечивает возможность перемещения от целого (агрегата) к его частям (свойствам).
Агрегация может обозначать, а может и не обозначать физическое включение части в целое. На рисунке А.11.12 приведен пример физического включения (композиции) частей (Двигателя, Сидений, Колес) в агрегат Автомобиль. В этом случае говорят, что части включены в агрегат по величине.
Рисунок А.11.12 - Физическое включение частей в агрегат
На рисунке А.11.13 приведен пример нефизического включения частей (Студента, Преподавателя) в агрегат Вуз. Очевидно, что Студент и Преподаватель являются элементами Вуза, но они не входят в него физически. В этом случае говорят, что части включены в агрегат по ссылке.
Рисунок А.11.13 - Нефизическое включение частей в агрегат |
Скачать 7.87 Mb.
