1. 12.DFD модель. Назначение. Область применения. Элементы модели.

DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации — Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На приведенной ниже иллюстрации использована нотация Гейна-Сарсона.

 

 

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы — структурной компоненты разрабатываемой системы.

Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы — диаграмма SADT, диаграмма Диаграмма вариантов использования.

Как применяется:

• Проектирование схемы документооборота
• Проектирование информационного обеспечения
• Проектирование модели защиты данных

Элементы модели:

• СОБЫТИЯ (ПРОЦЕССЫ) — преобразования входных в выходные данные в соответствии с определенным алгоритмом.
• ВНЕШНИЕ СУЩНОСТИ — материальный объект или физическое лицо, представляющее собой источник или приемник информации. 
• НАКОПИТЕЛИ — абстрактное устройство для хранения информации, которую можно сохранить и извлечь. Физические реализуется в виде бумажных носителей, дисков и т.д.
• ПОТОКИ — определяет информацию, передаваемую от источника приемнику.     поток должен отражать детализированное описание данных (фамилия, дата, номер счета и т.д.)
• СПЕЦИФИКАЦИИ

13.Структура информационно-логической модели АСОИиУ. ERD модель. Назначение. Область применения. Компоненты и диаграммы

Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью.  ВАЖНО:  Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. 

Проектирование ИЛМ должно выполняться с учетом следующих исходных данных:

• ТЗ: нефункциональные требования к АСОиУ 
• ТЗ: требования к информационному обеспечению 
• инфологическая модель или DFD модель
• описание бизнес-модели 

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

Оценка ИЛМ:

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

ERD:

Модель “сущность — связь” (МСС) (entity — relation diagram — ERD) — является неформальной моделью предметной области (ПО) и используется на этапе инфологического проектирования БД. Моделируются объекты ПО и их взаимоотношения. Модель ERD была разработана П. Ченом.

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

• Достоинства МСС:
• относительная простота;
  однозначность;
  применение естественного языка;
  доступность для понимания.

Информация о проекте представляется с использованием графических диаграмм.
Для построения МСС используются 3 основных элемента: сущность, атрибут и связь.

Сущность – собирательное понятие, абстракция реально существующего объекта, процесса или явления, о котором необходимо хранить информацию в системе. Примеры сущностей: материальные (предприятие, сотрудники), нематериальные (описание явления, реферат). Отображается в виде прямоугольника- должна обладать уникальным идентификатором; один или несколько атрибутов.

Атрибут – поименованнная характеристика сущности, его роль – описание свойств сущности: (сущность: КНИГА, атрибуты: НАЗВАНИЕ, АВТОР) и идентификация экземпляра сущности – т.е. каждый экземпляр сущности должен иметь уникальное имя — В качестве имени выступает один или несколько атрибутов. Например, «НОМЕР ЗАЧЕТНОЙ КНИЖКИ» или «НОМЕР» и «СЕРИЯ ПАСПОРТА ; м.б. обязательным и необяз-ым.

Связи — средство представления отношений между сущностями, отображаются при помощи линий именованных ассоциацией между 2 сущностями. Связь характеризуется типом (1:1, 1:N, N:М) и классом принадлежности (обязательный и необязательный). Если каждый экземпляр сущности участвует в связи, то класс принадлежности – обязательный, иначе – необязательный.

14.Информационное обеспечение АСОИУ. Внутримашинное и внемашинное обеспечение. Классификация внтуримашинного обеспечения.

Информация – это:

• Сведения об отдельных объектах, явлениях, представленные на определенном языке, хранимые на внешнем носителе и пригодные для обработки на ЭВМ
• Сведения об отдельных объектах, явлениях, снимающие неопределенность
• Сведения, характеризующие отдельный объект, явление в целях исследования системы

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

  Информационное обеспечение ИС включает 2 комплекса:

• внемашинное (классификаторы технико-экономической информации, документы, методические инструктивные материалы) 
• внутримашинное (макеты/экранные формы для ввода первичных данных в ЭВМ или вывода результатной информации, структуры информационной базы: входных, выходных файлов, базы данных).

Требования к информационному обеспечению:

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

Внутримашинное обеспечение. 

Классификация:

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

15.Структура сложных программных систем. Характеристики оценки структуры программной системы. 

Программное средство – программа, предназначенная для многократного применения

Программный продукт – набор машинных программ, процедур и документации 

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

программное изделие в автоматизированной системе — Программное средство, изготовленное, прошедшее испытания установленного вида и поставляемое как продукция производственно-технического назначения для применения в АС

Стадии создания:

• Моделирование структуры
• Разработка алгоритмов
• Кодирование, отладка
• Тестирование
• Сборка, компоновка
• Интегральное тестирование

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

Под моделированием программной структуры будем понимать процесс синтеза структуры в соответствии с заданными критериями эффективности ПК или в соответствии с НФТ и ФТ ТЗ

Этапы моделирования структуры:

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

1. 16.Структура сложных программных систем. Моделирование многоуровневой структуры.

17.Логический анализ структур. Связность в программных системах. 

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

Существует 7 типов связности:

• Функциональная связность
• Последовательная связность
• Информационная связность
• Процедурная связность
• Временная связность
• Логическая связность
• Связность по совпадению

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

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

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

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

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

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

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

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

18.Логический анализ структур. Сцепление в программных системах

Сцепление (Coupling) — мера взаимозависимости модулей по данным. Сцепление — 

внешняя характеристика модуля, которую желательно уменьшать. 

Количественно сцепление измеряется степенью сцепления (СЦ). Выделяют 6 типов

сцепления: 

• Сцепление по данным (СЦ=1). Модуль А вызывает модульВ. Все входные и выходные

параметрывызываемого модуля – простые элементыданных. 

• Сцепление по образцу (СЦ=3). Вкачестве параметров используются структурыданных. 
• Сцепление по управлению (СЦ=4). Модуль А явно управляет функционированием

модуляВ, посылая ему управляющие данные. 

• Сцепление по внешним ссылкам (СЦ=5). Модули А иВссылаются на один и тотже

глобальный элемент данных. 

• Сцепление по общей области (СЦ=7). Модули разделяют одну и туже глобальную

структуру данных. 

• Сцепление по содержанию (СЦ=9). Один модуль прямо ссылается на содержание

другого модуля (через его точку входа).

1. 19.Пользовательский интерфейс АСОИиУ. Правила построения  интерфейса.

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

Джеф Раскин 

(независимый консультант по разработке компьютерных интерфейсов и систем, Участник команды по созданию компьютера Apple Macintosh) 

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

Юзабилити (usability ): степень, в которой продукт может быть использован определенными пользователями для достижения поставленных целей эффективно, экономично и с удовольствием при определенном контексте использования для достижения заданных целей и мотивов (Пункт 3.1 стандарта ISO 9241-11)

Роль интерфейса в эффективности применения АС:

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

Ориентация интерфейса:

• Дизайн, ориентированный на пользователей
• Дизайн, ориентированный на задачи
• Дизайн, ориентированный на мотивы пользователей

Критерии оценки интерфейса (показатели Шнейдермана):

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

 

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

1. 20.Инструментальные  средства проектирования АСОИиУ. CASE – средства.

Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО. Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты; репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость; графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС; средства разработки приложений, включая языки 4GL и генераторы кодов; средства конфигурационного управления; средства документирования; средства тестирования; средства управления проектом; средства реинжиниринга. CASE-средства можно классифицировать по следующим признакам: применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам. Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы: средства анализа, предназначенные для построения и анализа моделей предметной области; средства анализа и проектирования, поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций. Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных; средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных для наиболее распространенных СУБД. К ним относятся Erwin, S-Designor и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV; средства разработки приложений: Developer/2000 (ORACLE), Delphi (Borland) и др; средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.. Вспомогательные типы включают: средства планирования и управления проектом; средства конфигурационного управления; средства тестирования; средства документирования.