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


25 Графическое представление диалога. Подсети
Транзитивная сеть может включать большое число состояний, тогда целесообразнее их группировать по смысловому признаку. Каждая такая подсеть отображается на общей диаграмме и имеет собственную детализацию.
Достоинства и недостатки простой транзитивной сети
+
Точное описание формальное диалогов
Диалог реализуется в простой табличной форме
Новый сигнал добавить достаточно просто
-
Возможность не эффективного использования памяти
Система помнит только одно состояние. Нельзя прервать диалог, выполнить какие либо действия и вернуться обратно.
26. Графическое представление диалога. Простая транзитивная сеть
Транзитивная сеть не строится для всей системы в целом.
Пусть имеет приложение помогающее строить запросы к базе данных. (построитель запросов).
Будут необходимы: элемент TEdit(для ввода имени таблицы и значение параметров) TMemo - для выбора полей запроса заполняется в зависимости от выбранных таблиц. CompMemo – содержит операции отношений; logMemo – для хранения логических операций; TGread – для отображения результатов запросов ОК – выполнение запросов Next для формирование условий

(1) Таблица помешается во From, а поля в Memo
(2) Выбор полей
(3) Добавление Where
27. Графическое представление диалога. Рекурсивно-транзитивная сеть
Основным признаком построения такой сети является первое – выделение подсети обладающей всеми характеристиками основной сети. Есть свое стартовое, конечное. Второго – переход в эту подсеть может осуществляться из нескольких состояний, а возврат в состояние явившееся точкой входа. Рекурсия не всегда подразумевает вызов сети самой из себя. Имеет в виду возврат в точку вызова. Конечный автомат дополняется двумя элементами. Множество элементов стека и второй начальное состояние стека.
28. Жизненный цикл информационных систем: этапы планирования разработки, определения требований, сбора и анализа требований, проектирования БД и выбора целевой СУБД
Жизненный цикл информационных систем – это период их создания и использования, охватывающий различные состояния, начиная с момента возникновения необходимости в такой системе и заканчивая моментом ее полного выхода из употребления у пользователей.
Жизненный цикл информационных систем включает в себя четыре стадии: предпроектную, проектировочную, внедрение, функционирование. От качества проектировочных работ зависит эффективность функционирования системы, поэтому каждая стадия разделяется на ряд этапов и предусматривает составление документации, отражающей результаты работ.
На предпроектной стадии можно выделить следующие этапы:
1) Сбор материалов для проектирования – предусматривает разработку и выбор варианта концепции системы, выявление всех характеристик объекта и управленческой деятельности, потоков внутренних и внешних информационных связей, состава задач и специалистов, которые будут работать в новых технологических условиях, уровень их подготовки, как будущих пользователей системы.
2) анализ материалов и формирование документации – составление задания на проектирование, утверждение технико-экономического обоснования.
Для успешного создания управленческой информационной системы всесторонне изучаются пути прохождения информационных потоков, как внутри предприятия, так и во внешней среде.
Информационная система – ресурсы, которые позволяют выполнить сбор, корректировку и распространение информации. Типичная информационная система (ИС) состоит из БД, ПО БД, прикладного ПО, аппаратное обеспечение и персонал.
Жизненный цикл ИС.
Складываются ситуации, когда при внедрении ИС требуется постоянное сопровождение, состоящее из исправления ошибок, реализации новых требований пользователей, кроме того, требуется перенос систем на более современные платформы. В результате затраты на разработку и сопровождение ПО растут быстрыми темпами, эта
ситуация называется кризисом ПО.
Неудачи при создании ПО обычно вызваны следующими причинами: отсутствие полной спецификации требований; отсутствие правильной методологии разработки; недостаточная степень разделения проекта на составные части для осуществления эффективного контроля за исполнением.
Для разрешения этих проблем предложен структурный подход к разработке ПО, называемый жизненным циклом. ЖЦ ИС выглядит следующим образом как показано на рисунке.
1 – Планирование разработки ИС;
2 – Определение требований к системе;
14 – сбор и анализ требований к с-ме;
3 – Концептуальное планирование БД;
4 – Логическое проектирование БД;
5 – Физическое проектирование БД;
6 – Проектирование БД;
7 – Выбор целевой СУБД;
8 – Разработка приложений;
9 – Реализация;
10 – Создание прототипов;
11 – Конвертирование и загрузка существующих
данных;
12 – Тестирование
13 – Эксплуатация и сопровождение
Планирование разработки ИС. Выполняются подготовительные
действия, позволяющие с максимально возможной эф-тью реализовывать
этапы ЖЦ. На этом этапе решаются следующие задачи: определение
бизнес-плана и целей организации с последующим выявлением
ее потребностей в ИТ; оценка показателей уже существующих ИС с целью
выявления их сильных и слабых сторон; определение возможностей использования ИТ для достижения конкурентного преимущества фирмы.
Для поддержки планирования разработки ИС м. б. построена корпоративная модель данных, чаще всего она отображается как упрощенная модель «сущность-связь» и на нее наносятся структурные подразделения. Такая модель позволяет оценить основные эл-ты информации, а также взаимодействие между структурными подразделениями.
Планирование разработки так же может включать принятие и разработку стандартов. Эти стандарты могут касаться методики сбора и документирования документов, а так же разработки программных продуктов.
Определение требований к с-ме. Определяется диапазон действий, границы разрабатываемой ИС, состав пользователей и область применения.
Сбор и анализ требований к с-ме. На этом этапе собирается и анализируется информация той части предприятия, для которой разрабатывается ИС. Результатом этого анализа является полный набор требований пользователей к системе, обычно информация собирается следующим образом: опрос работников организации; наблюдение за деятельностью предприятия; изучение документов; использование опыта разработки предыдущих ИС; анкетирование.
Собранная на этом этапе информация должна включать используемую и генерируемую инфо, подробные сведения о выполняемых транзакциях, список требований с указанием их приоритетов. Собранная на этом этапе информация м. б. плохо структурирована и неформализована, поэтому требуется использовать специальные методы для ее формализации.
Проектирование БД. На этом этапе создается проект БД, предназначенный для поддержки функционирования, организации и достижения ее целей.
Концептуальное проектирование. Создается модель данных, независящая от любых аспектов физического представлений данных, прежде всего от типа СУБД и языка программирования.
Логическое проектирование. Создается модель данных с учетом выбранной модели организации данных, но эта модель не должна зависеть от конкретной СУБД. Кроме того, на этом этапе проводят нормализацию полученной схемы данных, если выбрана реляционная СУБД.
Физическое проектирование. Создается описание реализации БД на запоминающих устройствах с указанием способов хранения и методов доступа к данным. Для реляционной модели этот этап включает следующее: создание набора таблиц и ограничений для них; определение методов доступа к данным и разработка средств защиты проектируемой с-мы.
Выбор целевой СУБД. Выбор СУБД осуществляется с одной стороны на основании требований пользователей к системе и с другой стороны на основе финансовых особенностей организации. Выбор целевой СУБД осущ-ся после концептуального проектирования, но до построения логической модели.
29. Жизненный цикл информационных систем: этапы разработки приложений, создания прототипов, реализации, конвертирования и загрузки данных, тестирования, эксплуатации
Жизненный цикл информационных систем – это период их создания и использования, охватывающий различные состояния, начиная с момента возникновения необходимости в такой системе и заканчивая моментом ее полного выхода из употребления у пользователей.
Жизненный цикл информационных систем включает в себя четыре стадии: предпроектную, проектировочную, внедрение, функционирование. От качества проектировочных работ зависит эффективность функционирования системы, поэтому каждая стадия разделяется на ряд этапов и предусматривает составление документации, отражающей результаты работ.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |


