1
|
- Дальневосточная Государственная Академия Экономики и Управления
|
2
|
|
3
|
- Продукция является изделием (по
ЕСКД), если она:
- социально значима,
- определены конкретные потребители,
- определены потребительские свойства продукции (показатели качества),
- определены критерии суммарной эффективности для потребителя и
производителя.
|
4
|
- Социальная значимость - общественная полезность для пользователей.
- Осознание потребителями полезности изделия в их деятельности.
- Реализуемость изделия в нужные сроки при имеющихся в наличии ресурсах.
- Обеспечение потребителю возможности практической доступности к изделию и
его освоения.
- Предоставление потребителю изделия гарантий его надежности и качества
(эффективности).
- Обеспечение возможности модификации изделия, развития и адаптации к
различным условиям использования.
|
5
|
|
6
|
|
7
|
- Компоненты (элементы),
- Набор однородных компонент (обеспечения),
- Набор разнородных компонент,
- Комплексы,
- Подсистемы,
- АС как система,
- Компоненты - внутренние обеспечения АС:
- ИО - информационное,
- АО - аналитическое,
- ПО - программное,
- МО - методическое,
- КО - кадровое,
- ОО - организационное,
- ПрО - правовое,
- ЛО - лингвистическое,
- ТС - техническое.
|
8
|
- Сформировалось понимание интегрированной БД как общего информационного
ресурса организации.
- Хранимые данные стали аналогичны большому компьютеру, который
одновременно используется многими пользователями с различными целями и
должен быть все время работоспособен.
|
9
|
- Проектные этапы:
- сбор сведений о ПО (анализ потребностей и описание ПО с использованием
так называемых "процессного" подхода и
"непроцессного", подхода);
- выбор языка представления т.н. "семантической" модели для
фиксации сведений о ПО, их последующего анализа и синтеза модели БД;
- анализ собранных сведений о ПО: классификация, формализация и интеграция
структурных элементов описания ПО, формализация как структурных, так и
процедурных ограничений целостности элементов в будущей модели ПО,
определение динамики экземпляров объектов ПО;
- синтез концептуальной модели БД: проектирование целостной концептуальной
схемы БД на выбранном языке семантического моделирования;
- выбор конкретной модели данных и СУБД для реализации БД;
- проектирование логической схемы БД для выбранной СУБД (называющееся
также "проектирование реализации");
|
10
|
- Проектные этапы
(продолжение):
- разработка физической структуры БД включая размещение БД по узлам;
- разработка технологии и процедур начального создания и заполнения БД;
- разработка технологии и процедур сопровождения БД;
- разработка универсальных программ доступа к БД и соответствующих
интерфейсов пользователей;
- информационное обеспечение разработки конкретных программ обработки
данных:
- обеспечение метаинформацией, данными контрольных примеров и др.;
- получение обратной связи от разработчиков прикладных программ и
пользователей ИС о полноте и эффективности организации БД;
- тестирование БД, ее развитие и улучшение (настройка) ее структуры.
|
11
|
- Использовалась дисциплина т.н. структурного анализа при проектном
подходе "сверху вниз". Структурность связывается с применением
иерархических структур для детализации данных и функций и
соответствующих, достаточно "жестких" проектных процедур.
- Проектная схема получила название "каскадной". Она хорошо
согласована с аналогичной схемой проектирования программного
обеспечения.
|
12
|
- Наличие целостной методологии проектирования позволило позаботиться о
систем автоматизации проектирования БД. Этому способствовало
использование активных интегрированных словарей-справочников данных
(DD/D, Data Dictionary/Directory).
- Возникли системы CASE - системы
для структурного проектирования БД и связанных с ними ИС,
ориентированные на модели данных, реализованные в различных СУБД.
- Наибольшую популярность получили CASE-системы для реляционных СУБД с
SQL-моделями данных, а DD/D переименовался в CASE-репозиторий
проектируемой ИС.
|
13
|
- Два основных направления развития CASE-систем и технологий
проектирования:
- CASE-системы для проектирования
собственно БД и интегрированные
инструменты, позволяющие и проектировать БД, и разрабатывать
использующие их прикладные программы.
- Часто интегрированность функций приводит к сращиванию CASE-системы с
одной из СУБД, на которую ориентированы CASE - средства разработки
прикладных программ.
- Итак, Классическая Мастерская проектировщика БД включает совокупность
классических структурных методов проектирования, набор соответствующих
инструментов моделирования, реализации, загрузки и сопровождения БД, а
также "каскадную" организационную схему выполнения этих работ
по принципу "сверху вниз".
|
14
|
- Появились новые возможности БД и способы их проектирования. Список типов
хранимых и обрабатываемых данных расширился до возможных пределов,
определяемых самым общим нормативным значением понятия
"данное".
- В корпоративные БД включаются не только неформатированные элементы и
полнотекстовые фрагменты, но также БД с геоинформацией, мультимедийные
БД, и это не исчерпывающий перечень.
- Если ИТ были одним из толчков к такому развитию ситуации, то они
оказались призваны и для того, чтобы обеспечить успех и саму возможность
планируемых реконструкций.
- Возникли новые требования к
архитектуре корпоративных ИС, как следствие - новые требования к
корпоративным БД
- Как саму ИС нельзя рассматривать в отрыве от ее пользователей, так и
новое проектирование должно рассматриваться как интеграция трех
составных частей: требований бизнес-реинжиниринга, человеческого фактора
и методов новых ИТ. Реальное объединение этих трех составных частей,
каждая из которых приобрела в 90-е годы качественно новое наполнение,
создало начала того, что можно назвать Н.С.П.
|
15
|
- Обеспечение максимальных
возможностей для каждого работника, то есть поддержка выполнения всех
бизнес-функций тем самым работником, который и получает конечный
результат.
- Со стороны ИС, БД и СУБД для
этого требуется:
- обеспечение средств доступа ко всем необходимым данным с использованием
распределенных БД,
- средств репликации данных,
- управления событиями в данных и процессах обработки транзакций;
- использование архитектуры и программных средств хранилища данных,
- средств Оперативной Аналитической Обработки Данных (OLAP),
- применение средств быстрой разработки приложений (RAD) для создания
"ИС руководителя" (EIS), средств поддержки принятия решений
(DSS) на основе хранилища данных, OLAP и RAD/EIS;
- применение средств DSS на основе анализа БД прецедентов, а также методов
логического вывода, нейронных сетей и нейрокомпьютерных технологий и
др.;
|
16
|
- предложение единого интерфейса пользователя для работы с разными
компонентами данных и приложений, использование в этом интерфейсе
средств, повышающих простоту поиска информации и обращения к конкретным
прикладным функциям, например функции геоинформсистем, гипертекстовые,
естественного языка, речевого ввода.
- разработка концепции и структуры корпоративной базы данных для новой ИС,
реализация структуры БД, предполагающая снятие (существенное уменьшение)
ограничений на ее развитие, в том числе при смене функций или
функциональных компонентов обработки информации:
- применение методов компонентного проектирования предметных БД как для
операционных БД, так и для исторических БД хранилищ данных, архивов
документов, геоинформационных и иных данных;
- разработка процедур компонентного изменения корпоративной БД при
изменении бизнес-процедур, видов деятельности, применяемых приложений и
географического размещения предприятия;
- постоянная актуализация понятийной модели деятельности предприятия для
учета новых понятий, возникающих при изменении прикладных компонентов на
функционально сходные и при изменении видов деятельности предприятия, и
построение на этой основе новых интерфейсов между компонентами ИС;
- динамическое администрирование фрагментами распределенной корпоративной
БД при изменении частоты их использования, при модификации их структуры
и при изменении их размещения.
|
17
|
- Язык SQL, бывший в 80-м году всего лишь одним из языков, представляющих
реляционную модель, стал реальным стандартом не только реляционной
модели данных, но и промышленных СУБД.
- В реальных разработках наиболее распространенных
организационно-производственных ИС в большинстве случаев или в большей
части объемов работ произошла замена средств разработки с SQL во
включающем 3GL-языке или языка 4GL процедурного типа на языки и инструменты
4GL с оконным интерфейсом на основе управления через меню и с
использованием элементов концепции объектно-ориентированного
программирования (и сохранением возможностей выхода на SQL и процедурный
язык).
- Возникли практически работающие стандарты de facto интероперабельной
работы с данными, в первую очередь - стандарт ODBC.
|
18
|
- Мультиплатформенность стала нормой, многопротокольность коммуникаций для
распределенных БД реализуется на основе стандартов и интероперабельных
мониторов транзакций, поддерживается "интернационализация"
хотя бы в части настроек на таблицы национальных кодировок данных.
- Вошли в практику новые структуры и типы данных, новые операции над
данными: неформатированные элементы, полнотекстовые БД и их обработка,
ГИС-данные, мультимедийные БД, гипертекстовые распределенные БД,
распределенная обработка и обработка, доставляемая вместе с объектом на
вход ИС.
- На практике наблюдаются шаги реальной интеграции упомянутых структур и
операций.
- Меняется подход к выбору СУБД, в первую очередь - для проектирования
корпоративных БД, эксплуатация и развитие которых планируются как
минимум на несколько лет.
- Все более используются экономические основания и критерии для выбора
СУБД.
|
19
|
- Как ответ на новые требования
можно рассмотреть рекомендации к новым методам и инструментам
проектирования БД. (Конечно, в предположении, что все новое есть ранее
кем-то уже обнаруженное старое.)
- Об исключении избыточности в данных
- Проблема консервации проблем
- Компонентная открытость и смысловая интероперабельность
- Разработка понятийных моделей и ССК
- Понятийные модели и последующие проектные работы:
- разработка совокупности разных предметных ИМ с выделением общих
информационных сущностей
- разработка функциональных моделей разных типов
- разработка семантически богатых средств поддержки пользователя и др.
|
20
|
- Технологическая открытость
- Проблемы объемов, временных характеристик и физического проектирования
- Проблема границ применимости основных методов проектирования
- В ходе исследований и практического проектирования должны быть
определены границы применимости двух концепций:
- проектирование БД как объекта, осознанно отделенного от прикладных
программ;
- и объектно-ориентированное проектирование, в котором объект
инкапсулирует и данные, и методы их обработки.
|
21
|
|
22
|
- ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ (ПО) - совокупность программ на носителях данных
и программных документов, предназначенная для отладки и решения задач
определенного функционального назначения.
- ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ - совокупность форм документов,
классификаторов, нормативной базы и реализованных решений по объемам,
размещению и формам существования информации, применяемой в АС при ее
функционировании.
|
23
|
- По типу функционального назначения различают:
- системное ПО;
- инструментальное ПО;
- прикладное ПО.
- Прикладное ПО может рассматриваться как
- Приложение - набор программ, автоматизирующий решение некоторых
прикладных задач пользователей.
- Программная система (ПС)- набор прикладных программ, рассматриваемый
как единый объект разработки.
|
24
|
- Составные части ПС:
- Данные - входные,
- - выходные,
- - хранимые.
- Процессы - последовательности инструкций или конъюнкции (соединения)
событий, оперирующие с данными. Протекание процессов определяется
условиями и ограничениями.
- Интерфейс - пользовательский,
- - документальный,
- - машинный.
|
25
|
- Классификационные признаки ПС
- По организации взаимодействия с пользователем:
- пакетные;
- интерактивные;
- реального времени.
- По архитектурным особенностям реализации.
- однопроцессорные;
- параллельные;
- распределенные.
- По особенностям строения:
- неинтеллектуальные (описание процесса):
- обработки данных,
- вычислительные,
- информационно-поисковые,
- интеллектуальные (моделирование механизма создания процесса).
- обработки транзакций,
- анализа данных,
- поддержки принятия решений,
- экспертные системы.
|
26
|
- ЖЦ - модель взаимосвязанных процессов создания и последовательного
изменения состояний системы от возникновения необходимости в ней до
полного выхода из употребления.
|
27
|
- СТАДИИ СОЗДАНИЯ АС
- (по ГОСТ 34.601-90)
- Формирование требований к АС.
- Разработка концепции АС.
- Техническое задание.
- Эскизный проект.
- Технический проект.
- Рабочая документация.
- Ввод в действие.
- Сопровождение АС.
|
28
|
- ХАРАКТЕРИСТИКИ ПС
- функции совместимость легкость использования
- скорость легкость освоения
- ресурсы надежность
|
29
|
- ПРОБЛЕМЫ РАЗРАБОТКИ ПС:
- Неопределенность и несогласованность представлений пользователей о том,
для чего нужна и что должна делать ПС.
- Отсутствие профессиональных знаний разработчиков о предметной области
автоматизируемой деятельности пользователей.
- Сложность как создаваемой ПС, так и самого процесса разработки.
- Высокая динамичность совершенствования ПТС и изменения деловых процессов
в организации, соизмеримая с временем создания ПС.
|
30
|
|
31
|
- Методология - совокупность механизмов (процедур, технологий и
процессов), определяющих деятельность на каждой фазе разработки
программных систем и объединенных единым философским подходом.
- Методологии различаются по выбранному базису аспектной декомпозиции
предметной области деятельности пользователей (совокупности моделей) и
базисной составной части ПС, являющейся ведущей в процессе
проектирования.
- Основные классы методологий
- 1. Процессно-ориентированные.
- 2. Дата-ориентированные.
- 3. Объектно-ориентированные.
- 4. Семантические.
|
32
|
- Процессно-ориентированные основаны на структурном подходе к
представлению процессов и потоков данных, с которыми они связаны.
Разработанные раньше других, наиболее широко они используются при
создании ПС обработки данных и вычислительного характера.
- Дата-ориентированные предусматривают первоочередное моделирование данных
в виде сущностей и связей между ними. После этого определяются связи
между выходными и входными данными для того, чтобы выработать требования
к процессам. Методологии этого класса широко используются при создании
информационно-поисковых систем на основе баз данных.
|
33
|
- 3. Объектно-ориентированные основаны на объектной декомпозиции
предметной области. В качестве объектов рассматриваются конкретные
предметы, а также реальные или абстрактные сущности. Каждый объект
содержит некоторую структуру данных, дополненную набором процедур,
описывающих способы манипулирования этими данными. Таким образом, объект
можно рассматривать как абстрактный тип данных, в котором соединены
(инкапсулированы) и данные и подпроцессы. Процессы в системе описываются
через последовательность происходящих в ней событий. В результате
событий объекты могут становиться активными или пассивными, а также
обмениваться между собой сообщениями, инициирующими возникновение новых
событий. По сравнению с предыдущими объектно-ориентированная методология
рассматривается как более гибкая из-за возможности создавать
разнообразные виды абстракции типов данных. За счет этого улучшается
модернизируемость ПС. В тоже время выигрыш в сроках разработки
достигается лишь при неоднократном применении этого подхода и
использовании в новом проекте объектов, разработанных для других систем.
- 4. Семантические предназначены для разработки интеллектуальных ПС.
|
34
|
- Метод - концептуальное
описание правил построения моделей, представляющих разные взгляды на
проект, с использованием специальной нотации.
- Методика - достаточно
детальное описание последовательности шагов, выполняемых при разработке
проекта системы на основе определенного метода.
- Метод конкретизирует
методологию, учитывая в явном или неявном виде:
- модель жизненного цикла, которая определяет порядок выполнения основных
этапов разработки.
- перечень и порядок использования документов (моделей), которые должны
быть получены после завершения каждого из этапов разработки.
|
35
|
|
36
|
|
37
|
- Перечень и
последовательность этапов разработки ПС определяются выбранными методами
ее создания, однако всегда можно выделить следующие этапы (фазы):
- анализ требований к программной системе, (что она должна делать, Ф -
представление);
- проектирование системы (как она должна это делать, П - представление);
- реализация (чтобы она действительно это делала).
- Модели жизненного цикла ПС (на фазе разработки):
- Каскадная модель - переход на следующий этап после полного окончания
работ по предыдущему этапу.
- Поэтапная модель с промежуточным контролем - итерационная модель
разработки ПС с циклами обратной связи между этапами.
- Спиральная модель - последовательное создание развиваемых версий
(прототипов), для каждого из которых последовательно выполняются все
этапы разработки.
- Быстрое создание приложений (RAD) - создание на основе
объектно-ориентированной методологии и соответствующих инструментальных
средств работающего прототипа системы, основным назначением которого
является совместное с заказчиком и пользователями осуществление анализа
и проектирования программной системы.
|
38
|
|
39
|
|
40
|
|
41
|
- СТАДИИ СОЗДАНИЯ АВТОМАТИЗИРОВАННЫХ СИСТЕМ (АС)
- ПО ГОСТ 34.601-90
- Формирование требований к АС.
- Разработка концепции АС.
- Техническое задание.
- Эскизный проект.
- функции системы и подсистем,
- состав комплексов задач и отдельных задач,
- концепция и укрупненная структура информационной базы,
- функции основных программных средств.
|
42
|
- Технический проект.
- функционально-алгоритмическая структура системы,
- алгоритмы решения задач и применяемые языки программирования,
- основные решения по организации и ведению информационной базы (в т.ч.
классификаторы).
- Рабочая документация.
- Разработка или адаптация программ (в т.ч. разработка документации).
- 7. Ввод в действие.
- автономная и комплексная наладка программных средств,
- предварительные испытания на работоспособность и соответствие ТЗ,
- опытная эксплуатация (при необходимости доработка ПО),
- испытания с целью приемки в постоянную эксплуатацию,
- обучение персонала.
- 8. Сопровождение АС.
|
43
|
- Системы программирования.
- Системы управления базами данных.
- Электронные таблицы.
- Интегрированная среда реализации:
- нераспределенной обработки (Microsoft Office);
- распределенной обработки без поддержки коммуникаций (клиентское ПО на
Ассess,
- серверное на MS SQL Server);
- распределенной обработки с поддержкой коммуникаций (средства создания и
поддержки технологий:
- groupware (Lotus Notes, Microsoft Exchange, GroupWise)
- workflow (Staffware, Action Workflow)
|
44
|
|
45
|
- Сформировалось понимание интегрированной БД как общего информационного
ресурса организации.
- Хранимые данные стали аналогичны большому компьютеру, который
одновременно используется многими пользователями с различными целями и
должен быть все время работоспособен.
|
46
|
- Проектные этапы:
- сбор сведений о ПО (анализ потребностей и описание ПО с использованием
так называемых "процессного" подхода и
"непроцессного", подхода);
- выбор языка представления т.н. "семантической" модели для
фиксации сведений о ПО, их последующего анализа и синтеза модели БД;
- анализ собранных сведений о ПО: классификация, формализация и интеграция
структурных элементов описания ПО, формализация как структурных, так и
процедурных ограничений целостности элементов в будущей модели ПО,
определение динамики экземпляров объектов ПО;
- синтез концептуальной модели БД: проектирование целостной концептуальной
схемы БД на выбранном языке семантического моделирования;
- выбор конкретной модели данных и СУБД для реализации БД;
- проектирование логической схемы БД для выбранной СУБД (называющееся
также "проектирование реализации");
|
47
|
- разработка физической структуры БД включая размещение БД по узлам;
- разработка технологии и процедур начального создания и заполнения БД;
- разработка технологии и процедур сопровождения БД;
- разработка универсальных программ доступа к БД и соответствующих
интерфейсов пользователей;
- информационное обеспечение разработки конкретных программ обработки
данных:
- обеспечение метаинформацией, данными контрольных примеров и др.;
- получение обратной связи от разработчиков прикладных программ и
пользователей ИС о полноте и эффективности организации БД;
- тестирование БД, ее развитие и улучшение (настройка) ее структуры.
- Это - дисциплина т.н. структурного анализа при проектном подходе
"сверху вниз".
Проектная схема получила название "каскадной".
|
48
|
|
49
|
- Положительные факторы применения этой схемы наблюдались в следующем:
- на каждой стадии формировался законченный, отвечающий критериям полноты
и согласованности набор проектной, а затем и пользовательской
документации, охватывающий все предусмотренные стандартами виды
обеспечения ИС: организационное, методическое, информационное,
программное, аппаратное и др.
- выполняемые в логичной
последовательности этапы работ достаточно очевидным образом
позволяли планировать сроки завершения всех работ и соответствующие
затраты.
|
50
|
|
51
|
- ”Обследование”, общий анализ ситуации в организации и разработка общего
обоснования целесообразности создания ИС: общий системный и ситуационный
анализ текущего состояния и целей организации, ее масштабов,
возможности, стоимости и способов разработки ИС, решающей задачи,
способствующие достижению целей предприятия.
|
52
|
- "Концепция, ТЗ":
- исследования требований предприятия и пользователей, выработка вариантов
и рекомендаций по разработке ИС, разработка ТЗ на проектирование ИС в
целом и ЧТЗ по подсистемам,
- анализ критических факторов
успеха и риска с использованием системного и ситуационного анализа,
- обследование предприятия методами
анализа документов, интервью, прямых наблюдений, хронометража и др.,
определение соответствия существующей оргструктуры, функций, документов
и др. целям предприятия, проектирование более целесообразных и
учитывающих создаваемую ИС оргструктуры, набора и иерархии функций
("задач"), видов документов и правил документооборота,
вычленение предметных БД, определение взаимосвязей между ними,
- разработка предложений по
изменениям на предприятии, затрагивающим оргструктуру, документооборот и
др.,
- построение недетализированных
моделей БД и функций ИС (с использованием диаграмм данных Ч. Бахмана,
модификаций ER-модели П. Чена, функциональных моделей по стандартам
IDEF0, по методике HIPO или др.),
- сбор и описание детальных требований к составу данных и алгоритмам
реализации функций.
|
53
|
- "Эскизный проект":
- разработка архитектуры будущей ИС
в рамках эскизного проекта,
- построение нормализованной
реляционной или сетевой модели БД (методы получения нормальных форм
Бойса-Кодда, четвертых и пятых нормальных форм),
- определение принципов организации
в ИС интерфейсов конечного пользователя (принципы эргономики, переход от
командного интерфейса к диалоговым режимам "вопрос-ответ",
"управление через меню"),
- определение модульной иерархии
(верхние уровни) программного обеспечения ИС (модульное
программирование, метод HIPO),
- определение принципов организации
аппаратного компьютерного комплекса, на базе которого должна
функционировать ИС (расчеты физических параметров ИС: объемов БД,
временных характеристик отдельных операций доступа к данным, целых
функций и режимов в целом, организации компьютерных сетей, ),
- определение основных
оргмероприятий по созданию и вводу в действие ИС,
- определение совокупности
требований к приемке будущей ИС,
- определение сроков, состава работ
и их стоимости для последующих работ по ИС.
|
54
|
- "ОПОЗДАНИЕ"
- "БЕСПОЛЕЗНОСТЬ"
- Альтернатива такому подходу требовалось получение с помощью ИС
качественно новых результатов, позволяющих осуществлять оптимальное
управление производством в целом, динамически менять управление
производственными процессами на предприятии, принимать лучшие
управленческие решения, встраивать контроль качества и рациональное
управление внутрь производственных процессов, использовать их самими
производственными коллективами.
|
55
|
- Наличие целостной методологии проектирования позволило позаботиться о
систем автоматизации проектирования БД. Этому способствовало
использование активных интегрированных словарей-справочников данных
(DD/D, Data Dictionary/Directory).
- Возникли системы CASE - системы
для структурного проектирования БД и связанных с ними ИС,
ориентированные на модели данных, реализованные в различных СУБД.
- Наибольшую популярность получили CASE-системы для реляционных СУБД с
SQL-моделями данных, а DD/D переименовался в CASE-репозиторий
проектируемой ИС.
- Два основных направления
развития CASE-систем и технологий проектирования:
- CASE-системы для проектирования собственно БД,
- интегрированные инструменты, позволяющие и проектировать БД, и
разрабатывать использующие их прикладные программы.
- Часто интегрированность функций приводит к сращиванию CASE-системы с
одной из СУБД, на которую ориентированы CASE - средства разработки
прикладных программ.
- Итак, Классическая Мастерская проектировщика БД включает совокупность
классических структурных методов проектирования, набор соответствующих
инструментов моделирования, реализации, загрузки и сопровождения БД, а
также "каскадную" организационную схему выполнения этих работ
по принципу "сверху вниз".
|
56
|
- Появились новые возможности БД и способы их проектирования. Список типов
хранимых и обрабатываемых данных расширился до возможных пределов,
определяемых самым общим нормативным значением понятия
"данное".
- В корпоративные БД включаются не только неформатированные элементы и
полнотекстовые фрагменты, но также БД с геоинформацией, мультимедийные
БД, и это не исчерпывающий перечень.
- Если ИТ были одним из толчков к такому развитию ситуации, то они
оказались призваны и для того, чтобы обеспечить успех и саму возможность
планируемых реконструкций.
- Возникли новые требования к
архитектуре корпоративных ИС, как следствие - новые требования к
корпоративным БД.
|
57
|
- Все эти методы остались в арсенале разработчиков и в настоящее время.
- Однако они и соответствующие инструменты начинают совсем по иному
применяться в условиях BPR и открытой архитектуры ИС. Кроме того, теперь
они сочетаются с новыми методами, позволяющими достичь большей гибкости
и процесса разработки, и самой ИС, причем за меньшее время.
- В отношении собственно
классических методов изменения, в первую очередь, касаются качества их
компьютерной поддержки, т.е. применения новых ИТ для поддержки
классических методов:
- широкое применение графических диалоговых интерфейсов (диаграммы
структур данных, иерархий функций, потоков данных и др.), •использование
компьютерных сетей и работа с распределенными базами данных для
поддержки кооперативной групповой разработки (использование общих
словарей-справочников данных, теперь - "репозитариев"),
- постепенное расширение использования понятийных моделей и методов
объектного моделирования.
- Новые ИТ заставили включать в классические методики и соответствующие
новые функции. Как пример, это относится к средствам динамического
моделирования архитектур клиент-сервер и систем с распределенными базами
данных. Однако включение отдельных новых функций не меняло подхода в
целом и не устраняло описанных выше недостатков.
|
58
|
- ПОНЯТИЕ ОТКРЫТОЙ АРХИТЕКТУРЫ:
- Предполагало строгое соответствие формата передаваемых по сети сообщений
стандарту протокола обмена, наличие нескольких стандартных уровней
обмена сообщениями со стандартами протоколов для каждого уровня.
- Одновременно стал решаться вопрос переносимости баз данных.
- В понятие открытой архитектуры стал вкладываться более широкий смысл.
- Укажем лишь на интероперабельность: открытость системы, позволяющая
встраивать ее как компонент в сложную разнородную распределенную
информационную среду.
|
59
|
- ТРИ КАЧЕСТВЕННЫХ СКАЧКА В ИТ:
- Феномен персональных вычислений, основанный на постоянной доступности
работнику возможностей ЭВМ, в первую очередь - на использовании
персональных компьютеров.
- Феномен кооперативных технологий, состоящий в компьютерной поддержке
совместной согласованной работы группы работников над одним проектом.
- Феномен компьютерных коммуникаций, состоящий в резком увеличении
возможностей обмена любой информацией. Он возник, в частности, на основе
стандартизованных протоколов обмена данными прикладного уровня в
локальных и глобальных сетях.
|
60
|
- ПОНЯТИЙНАЯ МОДЕЛЬ КАК МИНИМАЛЬНАЯ ИНТЕГРИРУЮЩАЯ МОДЕЛЬ.
- Необходимость строить ИС на основе набора "покупных"
приложений разных поставщиков, причем набора, состав которого надо уметь
изменить в нужное время, привела к практической невозможности
использовать классические структурные технологии проектирования
интегрированных систем.
- Даже если "по большому счету" в новом приложении будут
выполняться те же функции, но, например, быстрее и в более удачной
компоновке, а информация хранится "всего лишь" в виде более
детальных сведений и т.п., то информационные и функциональные модели
могут отличаться друг от друга практически во всех деталях!
- Постепенно становилось ясно, что обе крайности неприменимы: ни
вульгарный позадачный подход, ни попытки разработки полностью
законченных больших ИС с заранее полностью спроектированной
интегрированной базой данных.
|
61
|
- Единственным достаточно стабильным интегрирующим элементом современной
ИС может являться только понятийная модель предметной области.
- Активные понятийные модели разрабатывались не только для хранения
описаний используемых понятий и связей между ними. Ставились цели
динамически формировать новые суждения, определять тождество или
сходство понятий, производить их интерпретацию вычислительного
характера. К таким моделям относятся разные представления семантических
сетей, некоторые специальные понятийные модели.
- В настоящее время слияние средств представления знаний с технологией
обобщенных объектов и стандартизацией в области объектно-ориентированных
представлений реально ведет на следующий, качественно новый уровень в
технологии системного проектирования.
- Как саму ИС нельзя рассматривать в отрыве от ее пользователей, так и
новое проектирование должно рассматриваться как интеграция трех
составных частей: требований бизнес-реинжиниринга, человеческого фактора
и методов новых ИТ. Реальное объединение этих трех составных частей,
каждая из которых приобрела в 90-е годы качественно новое наполнение,
создало начала того, что можно назвать Н.С.П.
|
62
|
- “Бизнес - процессы это логические серии взаимозависимых действий,
которые используют ресурсы предприятия (организации) для создания или
получения в обозримом будущем полезного для Заказчика (Объекта заботы)
выхода, такого как Продукт или Услуга”
- Главное в BPR - резкое ускорение реакции предприятия на изменение в
требованиях потребителя путем:
- постоянное повышение качества продуктов и услуг;
- трансформация и динамическое совершенствование организации работ;
- критерии качества исходят от потребителя;
- в центре внимания качество выполнения производственных функций
- исследуются и устраняются недостатки производственной системы, а не
отдельных работников;
- повышение роли решений и инициативы каждого работника;
- снимаются барьеры, установленные производственными подразделениями;
организуется групповая “артельная работа”
- один из определяющих факторов - обеспечение работникам возможности
гордиться результатами своего труда.
|
63
|
- Цели и методы BPR:
- резкое снижение затрат времени на выполнение функций;
- резкое снижение числа работников и других затрат на выполнение функций;
- глобализация бизнеса:
- работа с клиентами и партнерами в любой точке
мира;
- работа с клиентом в режиме 24*365 часа;
- работа на будущие потребности клиента;
- ускоренное продвижение новых технологий;
- движение в информационное общество.
|
64
|
|
65
|
|
66
|
|
67
|
|
68
|
- Первым из этапов разработки ПС, выполняемым непосредственно после
принятия решения о ее создании, является анализ. Ведущую роль в
выполнении этого этапа играют системные аналитики. Основной целью их
деятельности является достижение взаимного понимания между заказчиками и
потенциальными пользователями системы, с одной стороны, и
разрабатывающими ее проектировщиками – с другой, по вопросу о том, что
должна делать создаваемая система и в каких условиях она должна
работать.
- В результате анализа общие нечеткие распределенные знания о требованиях
к разрабатываемой системе должны быть преобразованы в точные описания
(модели) и задокументированы.
|
69
|
- Процессно-ориентированные методы анализа относятся к классу методов структурного анализа
(подход Баркера), основанных на следующих принципах:
- декомпозиции,
- иерархического упорядочивания,
- абстрагирования - выделение на каждом уровне иерархии своих,
существенных с некоторых позиций, аспектов системы и отвлечение от
несущественных с целью представления системы в наиболее простом и общем
для данного уровня иерархии виде,
- формализации - строгое следование применяемым методам,
- непротиворечивости - обоснованность и согласованность элементов моделей,
- независимости данных - модели данных должны быть проанализированы и
спроектированы независимо от процессов их логической обработки, а также
от их физической структуры и распределения по узлам обработки
информации.
|
70
|
- Структурный анализ начинается с общего представления о ПС, которое
затем детализируется, приобретая иерархическую структуру, включающее все
большее число уровней. Использование принципа декомпозиции облегчает
понимание функций, которые должна выполнять ПС, за счет их подразделения
на множества более мелких.
- Для обеспечения проектирования трех базисных составных частей ПС,
каждая из которых также является объектом разработки: 1) данных, 2)
процессов и 3) интерфейса, на этапе анализа используются три группы
моделей, иллюстрирующих:
- функции, которые эта система должна выполнять;
- состав и характеристики данных, а также отношения между ними;
- поведение системы, зависящее от времени и внешних событий, в частности,
от действий пользователей.
- Соответствующие модели получили название функциональных, информационных
и событийных. Примерами наиболее часто и эффективно применяемых моделей
каждой из групп являются следующие[1]:
- DFD (Data Flow Diagrams) – диаграммы потоков данных совместно со
словарями данных и спецификациями процессов;
- ERD (Entity-Relationhip Diagrams) – диаграммы «сущность – связь»;
- STD (State-Transition Diagrams) – диаграммы переходов состояний.
[1] Калянов Г.Н. CASE структурный системный анализ (автоматизация
и применение). М., 1996.
|
71
|
- Обязательной и основной в процессно-ориентированном анализе является
функциональная модель, например, в виде DFD. DFD показывает внешнее по
отношению к ПС источники и получатели данных, определяет логические
функции (процессы) и группы элементов данных, связывающие одну функцию с
другой, а также указывает логические хранилища данных к которым процессы
имеют доступ (см.слайд диаграммы потоков данных). Функции или процессы,
их реализующие, могут быть представлены в виде некоторой деятельности по
преобразованию потока входных данных в поток выходных данных. Структуры
потоков данных и определения их компонентов хранятся в словаре данных.
|
72
|
|
73
|
- Каждый процесс может быть детализирован с помощью DFD нижнего уровня.
Когда дальнейшая детализация с использованием DFD перестает быть
полезной, переходят к другим средствам описания процессов. Содержимое
каждого хранилища также сохраняют в словаре данных. Модель данного
хранилища представляется в виде ERD. При необходимости DFD может быть
также дополнена STD, описывающей поведение системы. На следующем слайде
представлена схема, иллюстрирующая иерархическую структуру получаемых на
основе процессно-ориентированных декомпозиции описаний.
|
74
|
|
75
|
- Перечисленные средства могут быть использованы для полного описания как
существующей организационной системы, деятельность которой
автоматизируется, так и разрабатываемой системы.
- Отметим, что представленная совокупность моделей является универсальной
с точки зрения полноты представления всех трех базисных составных частей
ПС. Оборотной стороной этой универсальности является избыточность как
всего набора моделей, так и основания моделей – DFD, которая возможна
при превалировании процессной составляющей ПС над остальными, особенно
информационной. Строго говоря, ERD является неотъемлемой частью набора
моделей, характерных для методологий проектирования, ориентированных на
данные. В связи с этим для анализа функциональных требований могут
использоваться и другие методы, предусматривающие получение моделей,
отличающихся от диаграмм потоков данных. Одним из недостатков DFD является
использование в качестве структурного представления ориентированного
графа, в вершины которого отображаются и данные и процессы, что
затрудняет восприятие и снижает эффективность проводимой декомпозиции.
Рассматриваемые далее методы лишены этого недостатка, хотя это и сужает
область их использования.
|
76
|
- Метод HIPO (Hierarchic Input-Process-Output) – диаграмм, разработанный
фирмой IBM, характеризуется следующими основными чертами:
- использование трех элементов: вход, обработка, выход;
- способностью переставлять связь между входными и выходными данными и
процессом обработки;
- возможность декомпозировать систему иерархически, не вовлекая излишне
мелкие детали.
- Процесс специфицируется как центральный блок диаграммы и соединен с
элементами, составляющий вход и выход (см. рисунок)
|
77
|
|
78
|
- Процедура анализа с использование HIPO-диаграмм такова:
- начать с наивысшего уровня абстракции, содержащего единственный процесс;
- идентифицировать имеющийся на уровне вход, выход (то есть определить
перечень данных, их тип, структуру и диапазон изменения) и процесс
(процессы);
- соединить каждый процесс с соответствующими ему элементами входа и
выхода, используя HIPO-диаграммы;
- детализировать диаграмму на следующем уровне иерархии, декомпозируя
процессы на подпроцессы, используя шаги 2-3.
- Заметим, что метод HIPO-диаграмм не предусматривает построение в явном
виде структурной модели, аналогичной диаграмме потоков данных.
|
79
|
- Метод функционального моделирования, входящий в методологию SADT (Structured
Analysis and Design Techniques), предусматривает, как и другие методы,
построения совокупности диаграмм, организованные в иерархические
структуры. В состав диаграмм входят блоки, соответствующие функциям
(процессам), и дуги, связывающие блоки и отображающие взаимосвязи между
ними (см. рисунок). В отличие от DFD и HIPO-диаграмм, содержащих лишь
информационные связи (вход-выход) в этом методе анализируется связи по управлению
и исполнению (механизму). Таким образом, диаграмма каждого уровня
представляет собой, как и DFD, структурные описания, однако в ней не
предусмотрены элементы (вершины), соответствующие хранилищам данных.
Заметим также, что наличие входов Управление позволяет частично отразить
информацию, содержащуюся в диаграммах переходов состояний (STD).
|
80
|
|
81
|
- В заключение отметим, что функциональные модели с использованием
рассмотренных методов могут разрабатываться не только на этапе анализа
требований, предъявляемых к ПС, но и на этапе ее проектирования при
определении функций, реализуемых программными модулями.
|
82
|
- Последовательность проведения анализа функциональных требований к ПС с
использование метода HIPO рассмотрим на примере программы решения
квадратного уравнения вида:
- ax2+bx+c=0.
- Напомним, что решение уравнения называется такое значение x, при
котором уравнение превращается в тождество. В силу своей простоты пример
не является, конечно, характерным для класса программных систем, именно
сложность которых и обуславливает необходимость проведения анализа. Тем
не менее только на простом примере можно показать суть используемых
методов. Вместе с тем даже этот простой пример иллюстрирует ряд
сложностей, с которыми приходится сталкиваться при проведении анализа.
|
83
|
- Процедура анализа начинается с построения HIPO-диаграммы на наивысшем
уровне абстракции, содержащим единственный процесс. Процесс P0
можно идентифицировать как «Найти решение уравнения». На первый взгляд,
не вызывает трудностей описание входных данных, это действительные
переменные a, b и c. Однако вопрос о диапазоне их изменения помогает
уточнить функциональные требования к программе. Действительно, можно
считать, что квадратное уравнение не вырождено. Тогда диапазон изменения
коэффициента a надо ограничить, потребовав a¹0. Но возможен и вариант использования программы,
предусматривающей произвольные значения коэффициентов уравнения, т.е.
неограниченность диапазона их изменения.
|
84
|
- Предположим, что имеет место последний вариант. Тогда описание выходных
переменных потребует дополнительного анализа. В зависимости от сочетания
значений коэффициентов могут быть следующие варианты решения уравнения,
приведенные в таблице. Таблицы такого вида называются таблицами решений.
В полном виде они используются на этапе проектирования. На этапе анализа
достаточно иметь столбцы, в которых помещаются значения указателя
варианта n и информация о виде решения. Предположим, что в качестве
выходных данных нам необходимо выдавать либо два числовых корня x1
и x2, либо один числовой корень x, либо символьное сообщение s,
содержащее информацию о «патологических» случаях. Заметим, что это не
самый удачный вариант выходной информации, однако мы остановимся на нем
в целях упрощения анализа.
|
85
|
|
86
|
|
87
|
- Можно указать два различных универсальных подхода к декомпозиции
процессов на подпроцессы. Один из них основан на чисто функциональной
декомпозиции, другой – на анализе специфики данных, в частности, их
вариативности или введении промежуточных данных (результатов).
- Декомпозируем исходный процесс P0 на три подпроцесса
(они будут рассматриваться и как
процессы первого уровня), выделив интерфейсные составляющие, связанные с
вводом и выводом информации, и подпроцесс нахождения решения (см.
рисунок).
|
88
|
|
89
|
- Такая декомпозиция позволяет сделать эти подпроцессы максимально
независимыми. Процесс первого уровня пронумерованы последовательно.
Каждый из процессов Р1 и Р3 имеет совпадающие
списки входных и выходных переменных, отличающихся на диаграмме лишь
написанием (строчные и прописные). Прописными буквами обозначается
информация, вводимая пользователем или отображаемая ему программой.
Строчными буквами обозначаются введенные данные или данные,
подготовленные для вывода.
- После построения всех диаграмм какого-то уровня необходимо определить,
какие из них нуждаются в детализации на следующем уровне иерархии.
Критерий необходимости детализации связан с целью анализа. Если мы
считаем, что полученная диаграмма дает приемлемый ответ на вопрос о
функциях системы, то дальнейшую ее декомпозицию можно не проводить. Если
же мы считаем, что полученное описание слишком общее, неопределенное или
неконкретное, то необходима детализация программы.
|
90
|
- В рассматриваемом примере процесс Р1 не нуждается в дальнейшей
детализации. Точнее учитывая интерактивный характер взаимодействия
пользователя с программой, в дальнейшем удобнее детализировать процесс
ввода, используя диаграммы перехода состояний. Процессы же Р2 и Р3
нуждаются в детализации в силу вариативности выходных данных этих
процессов. Декомпозиция процесса Р3 (следующий рисунок) основана на
вариативности типов отображаемых данных.
|
91
|
|
92
|
- Декомпозиция процесса Р2 (рисунок ниже) основана, кроме того, на
введении промежуточных переменных n и D. Использование n в качестве
промежуточной переменной естественно и необходимо, так как именно она и
определяет вариативность результатов в соответствии с таблицей. Что
касается дискриминанта D, то он, наряду с коэффициентами уравнения a, б
и c, определяет значение, принимаемое указателем n. Поэтому процесс
«Найти D» может быть определен как на втором уровне иерархии, так и
ниже.
|
93
|
|
94
|
- Нумерацию процессов нижних уровней можно осуществлять разными
способами. На двух предыдущих рисунках использована каскадная нумерация,
при которой число индексов в обозначении процесса равно номеру уровня
иерархии, последний индекс обозначает порядковый номер рассматриваемого
процесса как подпроцесса детализируемого процесса, а последовательность
всех индексов кроме последнего образует номер детализируемого процесса.
В частности Р232 является вторым подпроцессом процесса Р23 и принадлежит
третьему уровню иерархии (см. рисунок).
|
95
|
|
96
|
|
97
|
- На рубеже 70-х годов при проработки программы интегрированной
компьютеризации производства (ICAM) Министерства оборон США была
использована методология SADT (Structure Analysis and Design Technique),
что привело к стандартизации и публикации ее основных частей, получивших
в последствии название методологии IDEF (ICAM DEFinition).
- IDEF включает три метод построения IDEF-моделей, основанных на
графическом представлении проектируемых систем:
- IDEF0 – используется для создания функциональной модели, которая
является структурированным изображением функции проектируемой системы, а
также информации и объектов, связывающие эти функции;
- IDEF1 – применяется при построении информационной модели, которая
включает в себя структурное представление информации, необходимой при
поддержки функций системы;
- IDEF2 – позволяет построить динамическую модель, отображающую
функционирование систем во времени с использованием сетей Петри.
|
98
|
- Ниже будут рассмотрены основные понятия метода IDEF0-моделей на примере
решения квадратного уравнения.
- При этом важно уяснить, что IDEF0-модель используемая для более
глубокого понимания и анализа не только системы в целом или ее
окружения, но и того, как взаимодействуют ее компоненты. При разработке
новых систем методология IDEF0 вначале может применяться для определения
требований и функций, а затем – собственно для управления процессом
проектирования системы, которая удовлетворяет этим требованиям и
реализует эти функции. Для уже существующих систем IDEF0 может быть
использована с целью проведения анализа функций, выполняемых системой, а
также для указания механизмов, посредством которых они осуществляются.
|
99
|
- Как уже отмечалось, результатом применения методологии IDEF0 является
модель. Модель состоит из диаграмм, фрагментов текста и глоссария,
которые имеют ссылки друг на друга.
- Диаграммы – главные компоненты модели. На диаграммах все функции системы
и интерфейсы между ними представлены как блоки (функции) и дуги
(интерфейсы).
- Место соединения дуги с блоком определяет тип интерфейса (см. рисунок).
Данные, предназначенные для управлением выполнением функции или задающие
ограничения на ее выполнение входят в блок сверху, в то время материалы
иди информация, которые будут подвергнуты обработке входят в блок с
левой стороны. Механизмы (специалисты, технические устройства, программы
и т.п.), посредством которых осуществляется выполнение функций,
представляются дугами, входящими в блок снизу. И, наконец, результаты
выполнения функции показываются с правой стороны блока.
|
100
|
|
101
|
- В совокупности своей блоки и дуги диаграммы i+1-го уровня IDEF0-модели
используются для представления подфункций и связей между ними,
описывающих более общую функцию диаграммы смежного i-го уровня,
называемую «родителем».
- Постепенное введение все больших уровней детализации по мере создания
диаграмм обеспечивает полноту представления информации о проектируемой
системе.
- Построение IDEF-модели начинается с представления всей системы в виде
одного блока и дуг, отображающих интерфейсы с функциями вне системы.
Поскольку этот блок отображает систему в целом, то имя, указанное в
блоке, является общим для всей модели и присутствует на всех ее
диаграммах.
- Затем блок, представляющий систему в качестве единичного модуля,
детализируется на другой диаграмме с помощью нескольких блоков,
соединенных интерфейсными дугами (см. рисунок). Каждая из дуг имеет
метку, подсоединенную к ней выраженную в виде оборота существительного.
|
102
|
|
103
|
- В IDEF0 есть свои правила постепенного добавления деталей в процессе
декомпозиции. Модуль всегда делится не менее, чем на три, но не более,
чем на шесть подмодулей. Верхний предел – шесть – позволяет использовать
иерархию для описания более сложных объектов. Нижний предел – три –
гарантирует введение достаточного количества деталей, чтобы полученная
декомпозиция представляла интерес.
- Во всех случаях каждый подмодуль может содержать только те элементы,
которые входят в исходный модуль. Кроме того, модуль не может опустить
какие-либо элементы, т.е. «родительский» блок и его интерфейсы
обеспечивают контекст. К нему нельзя ничего добавить, и из него ничего
не может быть удалено.
- Ни последовательность, ни время не указываются на IDEF0-диаграммах в
явном виде. Обратные связи, продолжающиеся процессы и перекрещивающиеся
(во времени) функции могут быть легко изображены при помощи дуг.
|
104
|
- В основе методологии IDEF0 лежат следующие правила:
- Функциональный блок (или Функция) преобразует Входы в Выходы (т.е.
входную информацию в выходную), Управление определяет, когда и как это
преобразование может или должно произойти Исполнители непосредственно
осуществляют это преобразование.
- С дугами связаны надписи (или метки) на естественном языке, описывающие
данные, которые они представляют.
- Дуги показывают, как функции между собой взаимосвязаны, как они
обмениваются данными и осуществляют управление друг другом.
- Выходы одной функции могут быть Входами, Управлением или Исполнителями
для другой.
- Дуги могут разветвляться и соединяться.
- Функциональный блок, который представляет систему в качестве единого
модуля, детализируется на другой диаграмме с помощью нескольких блоков,
соединенных между собой интерфейсными дугами.
- Эти блоки представляют основные подфункции (подмодули) единого исходного
модуля.
|
105
|
- Анализ программных систем на основе программного пакета Design/IDEF
- В качестве примера, на основе которого будут показаны особенности работы
с программным пакетом Design/IDEF, возьмем задачу решения квадратного
уравнения. Основные параметры квадратного уравнения и алгоритм его
решения представлены выше.
- Создание листа верхнего уровня. После запуска программы новый проект
создается с помощью пункта New меню File. Первая модель, которая
создается в проекте, должна быть функциональная модель (IDEF0), поэтому
в появившемся окне "Select New Page Type" следует выбрать
методологию IDEF0 (см. рисунок). После нажатия на кнопку "OK"
создается страница верхнего уровня модели. На данной странице находится
только один блок, который должен представлять систему в виде единого
модуля. Все остальные блоки будут располагаться на страницах более
низкого уровня. Название блока должно отражать цель всего проекта.
|
106
|
|
107
|
- Появившаяся страница диаграммы верхнего уровня называется контекстной
диаграммой и содержит единственный выделенный IDEF-блок.
- Настройка среды проектирования. Прежде, чем создавать остальные блоки,
желательно сразу настроить среду проектирования, так как в противном
случае в дальнейшем придется устанавливать настройки для каждого
созданного блока в отдельности. Для этого в меню Edit, пункте Set
Attributes… необходимо настроить все шрифты, которые будут действовать
по умолчанию. Из предлагаемого списка шрифтов следует выбирать
кириллические.
- Далее в меню Edit, пункте Set Options… устанавливается максимальное
количество блоков на странице (Activities, Maximum Boxes), тип нумерации
(Activities, Numbering), кривизну стрелок (Arrows, Automating Routing),
валюту и точность вычислений (Cost) и др. (см. рисунок).
|
108
|
- В настройках атрибутов проекта (Edit, Set Page Attributes…)
устанавливаются соответствующие атрибуты. Также желательно проверить и
другие настройки из пунктов Set Colors…, Set User Options…, Set Settings…
из меню Edit.
|
109
|
- Создание и редактирование блоков. Для создания нового блока используется
пункт "IDEF Box" меню Create либо соответствующая кнопка на
панели инструментов. После выбора пункта или нажатия кнопки следует
указать место, где будет расположен новый блок. Панель инструментов
изображена на рисунке.
|
110
|
- Если требуется разместить несколько блоков на диаграмме, то для этого
может быть использован пункт "Place Boxes…" меню Create или
соответствующая ему кнопка. После выбора пункта или нажатия на кнопку в
появившемся окне необходимо будет ввести количество размещаемых блоков.
Новые блоки размещаются равномерно по диагонали из левого верхнего в
правый нижний угол.
- Размеры новых блоков устанавливаются по умолчанию. Размеры каждого блока
изменяются путем перетаскивания маркеров (черных квадратиков на границе
объекта), которые появляются после щелчка мыши на блоке.
- Для добавления текста в блок (надписывания блока) следует выбрать пункт
"Turn On Text" меню Modify, нажать на клавишу F2 на клавиатуре
или на соответствующую кнопку на панели инструментов. Режим ввода текста
выключается клавишей Esc.
- Замечание: Перенос текста на следующую строку в блоках происходит
автоматически в зависимости от ширины блока. Текст же в метке должен
быть перенесен вручную.
- Напечатайте в блоке A0 следующий текст: «Решение квадратного уравнения».
|
111
|
- На этой странице верхнего уровня блоку A0 необходимо для выполнения,
указанной в нем функции четыре дуги: одна входная дуга, одна управляющая
дуга, одна дуга механизма и одна выходная дуга. Дуги в Design/IDEF могут
быть созданы только между блоком другим блоком или между блоком и
меткой. При движении или изменении размеров объектов (блоков, меток)
соответствующие дуги остаются присоединенными к ним.
- Поэтому, прежде чем рисовать дуги необходимо создать и разместить на
диаграмме четыре метки:
- для входной дуги: «A, B, C»;
- для управляющей дуги: «Диалоговый режим»;
- для дуги механизма: «ПЭВМ»;
- для выходной дуги: «S, x, (x1, x2)».
|
112
|
- Создание и редактирование ярлыков. Для создания меток (ярлыков)
используется пункт Label меню Create, клавиша F3 клавиатуры или
соответствующая кнопка на панели инструментов. После нажатия следует
указать место, где будет введена надпись. Отмена режима ввода надписей
происходит при нажатии на клавишу Esc или на любую кнопку на панели
инструментов.
- Редактирование ярлыков происходит путем включения режима редактирования
текста (Modify, Turn On Text или клавиша F2 или соответствующая кнопка
на панели инструментов). Выключение режима происходит при нажатии
клавиши Esc.
|
113
|
- Создание и редактирование стрелок. Прежде чем рисовать дуги следует
задать режимы, влияющие на их создание. С этой целью откройте меню Edit®Set Options®IDEF0®Arrows. В появившимся
перечне команд выберете Lock Arrows, которая следит за тем, чтобы
нарисованные углы дуг были прямыми и Route Arrows, разбивающая дугу на
ломаные сегменты с прямыми углами так, чтобы дуга не пересекала, а как
бы обходила по пути другие блоки и метки.
- Для создания новой дуги необходимо выбрать пункт Arrow меню Create или
нажать на соответствующую кнопку на панели инструментов. Затем курсором
мыши следует нажать на точку диаграммы, откуда будет выходить дуга, и,
не отпуская кнопки мыши, протащить дугу до того места какого-либо
объекта, куда должна дуга войти.
- Изменение имеющейся на диаграмме стрелки производится с помощью
маркеров, появляющихся при ее выделении.
- Ветвление (объединение) стрелок происходит с помощью пунктов Branch (Join) меню Create или соответствующей кнопки
на панели инструментов. Дуга, подвергающаяся ветвлению (объединению)
должна быть предварительно выделена. После вызова процедуры требуется
указать место на любом из объектов диаграммы (объект начинает мигать при
приближении курсора мыши), куда (откуда) будет направлена ветвь.
|
114
|
- Контекстная диаграмма верхнего уровня
|
115
|
- Замечание: Дуги в Design/IDEF рисуются от точки на стороне исходного
блока или метки, где вы нажмете кнопку мыши. Если отпустить кнопку мыши
до завершения дуги, то дуга будет сегментирована. Для создания
корректного соединения дугой двух объектов необходимо указателем мыши
осуществлять небольшой заступ на объект, который при выполнении команды Arrow
примет форму дуги «®»,
где наконечник стрелы является «горячей» точкой указателя дуги.
Указатель дуги остается активным до тех пор, пока вы не отмените его
нажатием клавиши Esc или выбором другой команды. Двойное нажатие на
левую кнопку мыши вне блока или метки во время создания дуги удаляет эту
дугу.
|
116
|
- Декомпозиция блоков. В Design/IDEF каждая диаграмма в модели может быть
названа и иерархически связана. Существующая команда Decompose позволяет
создавать подстраницы контекстной диаграммы, на которых изображается
следующий уровень модели.
- Декомпозиция производится с помощью пункта Decompose меню Create или
соответствующей кнопки на панели инструментов. В результате декомпозиции
создается новый лист диаграммы более низкого уровня, перейти на который
можно двойным щелчком по декомпозированному блоку.
|
117
|
- Перемещение между страницами. Для перехода на родительскую или дочернюю
страницу используются пункты "Parent" и "Child" меню
Select или соответствующие кнопки на панели инструментов. Для перехода
на произвольную страницу может быть использовано иерархическое дерево
страниц проекта, которое вызывается пунктом "Page…" меню Select.
- Подстраница получает имя, в точности совпадающее с текстом внутри
декомпозированного блока и номер «P.2». Автоматически заполняются
переменные мастерской страницы: дата, контекст, узел и название.
- Блок A0 на родительской диаграмме имеет четыре дуги, соединяющие его с
метками. Текст этих меток будет автоматически перенесен на
страницу-наследник и помещен в невидимые прямоугольники, называемые
«портовыми узлами» и расположенные по краям страницы-наследника.
- Замечание: Если IDEF-страница не помещается целиком на экране выберете
команду Reduce в меню View, чтобы увидеть все портовые узлы. Выберете
команду Enlarge меню View, чтобы вернуться к 100-процентному масштабу.
|
118
|
- Диаграмма второго уровня будет содержать три функции: ввод данных, найти
решение и вывод данных.
- Для создания и размещения блоков, отображающих указанные выше функции
выберите команду Place Boxes в меню Create.
- Появится диалоговое окно, в котором будет выделено число «3»,
указывающее на количество создаваемых блоков. Вы можете напечатать любое
необходимое вам число, но не больше максимально допустимого числа
блоков, помеченного в этом диалоговом окне. Максимальное число блоков
может быть изменено в диалоговом окне Set Attributes… меню Edit.
- Кликните мышкой по полю OK для создания и размещения трех IDEF-блоков
вдоль диагонали страницы. Блоки нумеруются автоматически в соответствии
с режимом нумерации блоков, установленных в окне Set Attributes….
- Используя команду Turn On Text в меню Modify, впечатайте указанный выше
текст в соответствующие функциональные блоки.
|
119
|
- Затем нарисуйте дуги, соединяющие между собой функциональные блоки и
портовые узлы (контекстные метки). При этом следует имеет ввиду, что
контекстная метка «ПЭВМ» соединяется с тремя блоками (A1, A2, A3), а
метка «Диалоговый режим» - с двумя (A1, A3).
- Чтобы создать разветвляющуюся дугу между контекстной меткой «ПЭВМ» и
функциональными блоками A1, A2 и A3, нарисуйте дугу между указанной
меткой и блоком A1. Нажмите клавишу Esc для завершения создания дуги.
- Замечание: Если вертикальный участок дуги расположился слишком близко к
другому блоку, вы можете передвинуть его. Поместите графический
указатель на один из выделяющих квадратиков, расположенный в вершине
прямого угла и передвиньте его в новое положение. Дуга будет нарисована
заново.
- Сохраняя выделение этой дуги, выберете команду Branch в меню Create.
Появится сообщение в поле состояния: «Select the IDEF Box or label for
branch» (Укажите IDEF-блок или метку для разветвления). Поместите
указатель мыши на нижнюю сторону блока A2. Как только контуры указанного
блока замерцают, щелкните левой кнопкой мыши. Ветвь дуги будет
автоматически будет проведена от метки «ПЭВМ» вдоль исходной дуги до
точки разветвления, от которой ломаная дуга с прямым углом присоединится
к блоку A3.
|
120
|
- Как отмечалось ранее, каждая дуга может иметь свою метку.
Воспользовавшись командой Label в меню Create, создайте возле дуги,
соединяющий блоки A1 и A2 метку «a, b, c». Для присоединения метки к
дуге нажмите клавишу Esc, чтобы закончить создание меток, и выберете
команду Attach Label в меню Create. В поле состояния появится сообщение:
«Select the Arrow for attach» (Укажите дугу для присоединения).
Поместите указатель мыши на вертикальный сегмент дуги напротив метки.
Когда дуга замерцает, щелкните кнопкой мыши.
- В результате выполнения команды появится линия, соединяющая метку и
дугу, а в точку присоединения на дуге будет помещен маленький кружочек.
- Замечание: Design/IDEF позволяет произвести только одно присоединение
для каждой дуги.
- Создайте и присоедините метки для каждой из дуг на диаграмме второго
уровня, как показано на рисунке.
|
121
|
|
122
|
- На этом построение диаграммы второго уровня заканчивается. Для
построения диаграммы третьего уровня необходимо осуществить декомпозицию
блока A3 «Найти решение», используя команду Decompose меню Create.
- На диаграмме третьего уровня следует разместить четыре функционального
блока: найти D, найти числовое решение, найти символьное решение (см.
рисунок).
|
123
|
- Диаграмма третьего уровня
|
124
|
- Обратите внимание, что на полученной диаграмме третьего уровня не
удалось избежать пересечения стрелок, отображающих связи между
функциями. Для таких случаев в Design/IDEF предусмотрена возможность
построения мостов, позволяющих визуально отличать точки пересечения и
разветвления двух и более стрелок.
- Выберете команду Create Bridges в меню Edit®Set Attributes®IDEF0®Arrows. После ее выполнения в каждой точке
пересечения автоматически появится мост, как показано на предыдущем
рисунке.
- Design/IDEF также предоставляет большой выбор средств для изменения
внешнего вида объектов, что позволяет выделять их особые значения,
например, декомпозированный блок на родительской диаграмме.
- Заполнение декомпозированного блока IDEF-блока одним из имеющихся
орнаментов – это эффективный способ выделить его среди других блоков
страницы. В нашем случае декомпозированным блоком является блок A2.
- Чтобы перейти к блоку A2, декомпозиция которого представлена на текущей
странице, воспользуйтесь командой Parent в меню Select. Если к этому
времени вы по каким то причинам переместились с диаграммы третьего
уровня в другое место, используйте команду Page… в том же меню. В
результате выполения этой команды на экране будет отражена иерархия
уровней вышей модели (см. рисунок).
|
125
|
- Щелкните кнопкой мыши на уровне P2. На появившееся диаграмме выделите
блок A2 «Найти решение». Выберите в поле Fill в меню Edit®Set Attributes®Decomposed понравившиеся
вам орнамент и щелкните кнопкой мыши на поле OK. Чтобы текст в
заполненном блоке выделялся на фоне орнамента, поменяйте шрифт с
простого на жирный, воспользовавшись командой Box Text там же.
|
126
|
- Прежде чем закончить работу с диаграммой третьего уровня, рассмотри
ситуацию, связанной с пропуском одной из функций. Допустим, что при
декомпозиции функции «Найти решение» вы забыли о вычислении значения
параметра n и разместили на диаграмме третьего уровня три функциональных
блока, вместо четырех.
- В данном случае можно удалить три имеющихся блока и создать четыре
новых. Но если вы уже внесли в эти блоки информацию, которую вам не
хочется печатать заново, то возможен другой способ – вставка
дополнительного блока.
|
127
|
- Вставка производится с помощью команды IDEF Box в меню Create.
Выполнение этой команды приведет к изменению указателя мыши на указатель
блока. Необходимо поместить указатель блока в то место диаграммы, где
должен быть левый верхний угол дополнительного блока щелкнуть кнопкой
мыши. В результате будет создан IDEF-блок, размеры которого определены
по умолчанию.
- Новый блок получит ближайший свободный IDEF-номер, в нашем случае A24.
Поскольку этому блоку соответствует вторая на диаграмме функция, его
номер следует изменить, воспользовавшись командой Renumber Box… в меню Edit.
Появится диалоговое окно Renumber Box. В этом окне нужно пометить поле Renumber
All Boxes и щелкнуть кнопкой мыши на поле OK. Блоки диаграммы изменят
нумерацию на последовательную, начиная с выделенного вами
дополнительного блока, номер которого сменится на A22.
|
128
|
- Вставка дополнительного блока может привести к некорректному
расположению блоков, не оставляющему места для размещения
соответствующих дуг. На этот случай Design/IDEF предлагает несколько
способов выравнивания блоков относительно друг друга.
- I способ: изменение положения блока относительно двух смежных с ним
блоков.
- Для того, чтобы вставленный дополнительный блок (в нашем случае это A22)
расположился посредине между смежными с ним блоками необходимо выделить
его и выбрать команду Between из меню Modify®Align. В поле состояния появится сообщение: «Select
Node [box], Region or Page border as a Reference for Alignment» (Укажите
узел [блок], область или контур страницы в качестве ориентира для
выравнивания). Необходимо выделить первый из двух смежных блоков (в
нашем случае – A21). Сообщение в поле состояния изменится на предложение
выделить второй ориентир для выравнивания. В нашем случае им является
второй из смежных блоков – A23. После его выделения блок A22 будет
помещен между блоками A21 и A23 на равных расстояниях.
|
129
|
- II способ: равномерное расположение всех блоков на странице.
- Перед началом выравнивания блоков на странице, их необходимо
сгруппировать. Чтобы сформировать группу, включающую все блоки текущей
диаграммы следует нажать кнопку мыши, предварительно поместив указатель
чуть левее и выше первого из блоков и не отпуская ее перемещать
указатель, обводя все блоки выделяющим прямоугольником. После отпуска
кнопки мыши, каждый блок группы будет заключен в широкую черную рамку, а
указатель мыши превратиться в указатель группы.
- Замечание: Группу можно создать и по другому: выделить первый блок, а
потом щелкнуть кнопкой мыши при нажатой клавише Shift на остальных
блоках. Случайный щелчок кнопкой мыши вне членов группы может ее
отменить.
- Последующее выравнивание блоков, входящих в состав групп осуществляется
по команде Spread из меню Modify. На экране появится диалоговое окно, в
котором необходимо выбрать, например, «Horizontal», «Vertical» или «Diagonal», т.е.
выравнивание по горизонтали, вертикали или по диагонали.
- После проведения выравнивания нужно отменить группу щелчком кнопкой мыши
вне членов группы.
|
130
|
- Иногда помимо равномерного размещения блоков на странице возникает
необходимость в изменении их размера по определенному образцу. В Design/IDEF
предусмотрена возможность выравнивания размеров блоков по одному из них.
Для этого необходимо создать группу из блоков, размеры которых будут
изменяться, и выбрать команду Same Size в меню Modify. В поле состояния
появится сообщение: «Select Node [box] or Region as Model for Share
Change» (Укажите узел [блок] или область в качестве модели для изменения
формы).
- После появления сообщения нужно поместить указатель внутрь блока, форма
которого будет служить эталоном, и, как только его контур начнет
мерцать, щелкнуть кнопкой мыши. После чего все блоки, входящие в состав
группы будут совпадать по размерам.
- Для завершения модели вам осталось провести декомпозицию функционального
блока A23 «Найти численное решение», разместив на диаграмме четвертого
уровня два функциональных блока: найти x, найти (x1б x2) (см. рисунок).
|
131
|
- Диаграмма четвертого уровня
|
132
|
- На этом IDEF-модель рассмотренного примера завершена. Но прежде чем
отправит ее на печать, рекомендуется просмотреть диаграммы для проверки IDEF0
синтаксиса.
- В программном пакете Design/IDEF такая проверка автоматизирована. Для
этого выберите команду Validate… в меню File. В появившемся диалоговом
окне пометьте все поля, начинающиеся со слова Check.
- В разделе Report Options пометьте поле Display on Screen. Этот параметр
направит отчет на экран. После того как вы щелкните кнопкой мыши на поле
OK на экран будет выдан отчет проверки IDEF0 синтаксиса диаграмм вашей
модели (см. рисунок).
|
133
|
- Отчет о проверки синтаксиса модели
|
134
|
|
135
|
- Возможные методики проектирования отличаются по последовательности
использования результатов анализа (функциональных и информационных
моделей):
- 1. Последовательное использование моделей разных уровней иерархии.
- 2. Использование моделей нижнего
уровня иерархии.
|
136
|
|
137
|
|
138
|
|
139
|
|
140
|
|
141
|
|
142
|
- Общие принципы организации работ:
- конструирование такого решения бизнес-архитектуры, которое обеспечивает
"прорыв", т.е. предлагающего такую организацию
бизнес-процессов, которая в реальности может обеспечить радикальное
повышение итоговой эффективности;
- разработка бизнес-архитектуры и
ИТ-архитектуры производится с использованием прототипирования,
разработки лабораторных версий,
то есть имеет циклические, итерационные формы организации;
- крупные ИС требуют параллельной
циклической разработки нескольких компонентов ИС и соответствующих работ
(и затрат) на их комплексирование,
дополнительно к этому принцип постоянного реинжиниринга означает
постоянный процесс модернизации бизнес-архитектуры и, может быть,
бизнес-платформы предприятия, что предполагает организацию работ по
проектированию и развитию ИС в течение длительного периода.
- циклическая (спиральная) организация разработки ИС и программных систем
предлагается в качестве альтернативы быстрому прототипированию" как
средству ускорения разработки (время дорого).
|
143
|
|
144
|
- Параллельное компонентное проектирование ИС.
- На практике при отсутствии идеальных схем, полезно развивать циклическую
схему с применением методов компонентного и параллельного проектирования
с использованием интеграции компонентов на основе понятийных моделей.
- В этом случае организация разработки может быть графически представлена
как совокупность нескольких спиральных процессов параллельной разработки
или адаптации нескольких компонентов ИС с их последующей комплексной
стыковкой.
- Такая организация называется “Параллельное компонентное
проектирование"
|
145
|
- Адаптивные схемы организации Н.С.П.
- Н.С.П. не навязывает заказчику и разработчику общую для всех, типовую
схему обязательного выполнения полного цикла работ по BPR, или
тотальному реинжинирингу, или чему-нибудь подобному. С учетом реального
положения с ИС, реальных нужд предприятия и реальной его готовностью к
BPR выполняются те работы, которые может освоить это предприятие.
- Тем не менее, в общем случае в Н.С.П. исследуется необходимость и
возможность выполнения всех видов работ, потенциально необходимых
предприятию. В силу этого, предлагается построение гибких
организационных схем проектирования, заключающееся в построении и
динамическом уточнении адаптивной организационной схемы, ориентированной
на специфику конкретного предприятия, его внутреннее состояние и внешнее
положение. Адаптивность проявляется также и в том, что строится схема, в
соответствии с которой в процессе выполнения работ выбирается тот
вариант проектирования и будущей ИС, для которого готово предприятие или
может быть подготовлено за приемлемое время.
- Начальными являются аналитические экспертные процедуры, определяющие
состояние предприятия (организации) и его потребность в BPR и готовность к нему.
|
146
|
- "Реконструкции самих по себе бизнес-процессов недостаточно.
Организациям следует крепко усвоить, что в постоянно меняющейся,
неопределенной среде абсолютно необходимо конструирование
предприятия" (Мартин Дж.).
- Им перечисляются основные методы
ИТ, которые будут служить технологической базой будущей киберкорпорации.
Выделим из них два:
- объектно-ориентированное моделирование, которое заменит структурные
методы CASE-систем и позволит создавать приложения, напрямую моделируя
процессы с выделением в них многократно используемых элементов работ;
- компонентное программное обеспечение, состоящее из генерируемых на
основе шаблонов покупных компонентов и среды, позволяющей соединять
компоненты и создаваемые объекты.
|
147
|
- Эти методы ИТ являются прямыми методами Нового Системного
Проектирования, необходимость в которых предсказывалась давно В середине
90-х годов необходимость в них
стала предельно острой, в том числе для реализации смысловой
интероперабельности компонентов на уровнях персональных и кооперативных
метатехнологий.
- Необходимость в активных понятийных моделях в качестве минимальных
интегрирующих моделей подтверждается. В качестве стратегического плана и
для корпораций, и для профессионалов в ИТ Мартин Дж. предлагает лучше
проектировать стратегию развития: постоянны ситуации, в которых и
специалисты, и корпорации не имеют стратегического плана своего
развития, или выдают за него нечто другое, не зная того, в какую сторону
и как следует развиваться. Это подтверждает, что третьим проблемным
аспектом проектирования ИС является целенаправленная работа с людьми
(самым сложным компонентом ИС) для ясного и рационального решения
стратегических задач.
|
148
|
- Целесообразно сочетание двух правил:
- не поддаваться безоглядно на
"горячие" лозунги модных течений и, одновременно,
- не пропускать настоящие
изменения, которые должны включаться в практику проектирования.
- Целесообразно исходить из того, что корпоративная ИС проектируется как
информационно-управляющая система, включающая бизнес-архитектуру
предприятия, его персонал, используемую ИТ-архитектуру, и является
действующей частью т.н. "киберкорпорации", это значит, что в
виде ИС проектируется часть предприятия, которая непосредственно
осуществляет его "бизнес".
- Проектировать ИС как реализацию последовательности состояний системы в
развитии ее функциональных возможностей, причем таких состояний, в
каждом из которых ИС приносит те реальные (часто - частичные) полезные
результаты, которые нужны "для сегодня", и содержит
возможность развития для получения результатов, которые будут нужны
"для завтра".
- Учитывать необратимость требований, фиксируемых в подходе BPR, таких как
глобализация деятельности, снабжение работников всеми информационными и
функциональными средствами для возможности самостоятельного принятия
решений, предельное сокращение времени реакции на возникающие
потребности и др.
|
149
|
- Как ключевой элемент проектирования ИС осуществлять поиск,
конструкторскую реализацию и информационно-функциональное обеспечение
такого решения бизнес-архитектуры, которое обеспечивает
"прорыв", т.е. такую организацию процессов, которая в реальности
может обеспечить радикальное повышение итоговой эффективности
деятельности предприятия.
- Развивать применение понятийных моделей предприятий как базисного
интегрирующего слоя, позволяющего управлять (хотя бы и в ручном режиме,
через применение развитых тезаурусов) смысловой интеграцией отдельных
предметных БД, потоков документов в workflow, отдельных прикладных
компонентов.
- Продолжать локально использовать структурные модели, но в улучшенной
каскадной схеме работ, с применением прототипирования и других
ускоряющих методов. Переходить на сочетание иерархических структурных
моделей и открытых объектно-ориентированных подходов.
- Организовывать проектирование как "Параллельное компонентное
проектирование" - совокупность параллельных спиральных процессов
разработки или адаптации нескольких компонентов ИС с их последующей
комплексной стыковкой. Применять схему распределения ресурсов,
ориентированную на такое проектирование.
|
150
|
- Использовать принцип построения адаптивных схем организации проектного
цикла, приспосабливаемых к реальным потребностям и возможностям
предприятий в области проведения либо жесткого бизнес-реинжиниринга,
либо менее радикального развития. Использовать в адаптивных
организационных схемах процедуры и экспертизы, учитывающие специфику
положения предприятия на местном рынке и реальную готовность руководства
и остального персонала к реинжинирингу. Учитывать, что из трех составных
частей Н.П.С. работа с "человеческим фактором" чаще всего
является определяющей и наиболее критичной.
- Закладывать возможности перехода к постоянному конструированию
предприятия в будущем, учитывая в планах то, что оно будет вынужденно
базироваться на закладываемом сегодня фундаменте Информационных
Технологий, включая архитектурные решения, прикладные программы, а также
методы совершенствования деятельности предприятий.
|
151
|
|
152
|
- Основы Объектно-Ориентированного Подхода
- Объект - абстрактная или реальная сущность, обладающая индивидуальностью
и поведением, и имеющая атрибуты, значение которых определяют его
состояние.
- Объект - является представителем некоторого класса однотипных объектов.
- Класс - множество объектов, связанных общностью структуры и поведения.
- Два вида декомпозиции предметной области:
- 1. По принципу "целое - часть"
- - на объекты.
- A состоит из B.
- 2. По принципу "общее - частное"
- - на классы.
- A является обобщением B.
- Поведение характеризует то, как объект воздействует или подвергается
воздействию других объектов с точки зрения изменения состояния этих
объектов и передачи сообщений.
- Сообщение - воздействие одного объекта на другой с целью вызвать
соответствующую реакцию (выполнить процесс).
|
153
|
|
154
|
- Процессы - изменяют значения атрибутов;
- - формируют сообщения.
- Атрибуты - определяют состояние объекта;
- - определяют содержание
сообщения.
- ПРИНЦИПЫ ОБЪЕКТНОГО ПОДХОДА
- Инкапсуляция
- Наследование
- Полиморфизм
- Инкапсуляция (скрытие информации):
- интеграция данных и допустимых процессов их обработки, запрещающая любой
доступ к атрибутам объекта кроме как через его процессы;
- отделение внутренней структуры объекта (его реализации) от интерфейса с
ним.
|
155
|
|
156
|
- Наследование - возможность создавать из классов новые классы по принципу
"от общего к частному" путем добавления в новые классы атрибутов и процессов, отражающих их
индивидуальность, при сохранении
свойств классов-родителей (допустимо изменение процессов).
- Класс - множество объектов, связанных общностью структуры и поведения.
- Полиморфизм - способность объекта выбирать процесс на основе типов
данных, принимаемых в сообщениях; обеспечивает возможность различной
реакции объектов одного класса на одинаковые сообщения.
|
157
|
- Отношения между объектами
- Использование - возможность передачи сообщения от одного объекта к
другому.
- Включение - отражает отношение "целое - часть".
- Отношения между классами
- Наследование.
- Использование.
- Наполнение - отражает отношение между сборным классом, объекты которого
составлены из других объектов, и
классом "других" объектов.
- Метакласс - класс классов, позволяющий трактовать классы как объекты.
|
158
|
- ПРЕИМУЩЕСТВА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА
- распараллеливание работ
- простота внесения изменений
- гибкая архитектура и
модернизируемость
- повторное использование
программных компонент
- естественность описания
- НЕДОСТАТКИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА
- психологические трудности
- начальные финансовые затраты
- замедление работы приложений
из-за обращения к методу классов
- многочисленность операций и их
вызовов
- интенсивный обмен сообщениями
(при распределенной структуре)
|
159
|
- В результате ООА формируются:
- Общее описание проблемы - краткое изложение всех основных функций,
которые должны быть выполнены ПС.
- Перечни
- объектов, - атрибутов объектов,
- процессов, - атрибутов процессов.
- Диаграммы
- ORD - диаграмма отношений объектов;
- CHD - диаграмма иерархии классов;
- GCSD - диаграмма структуры "общее - частное";
- W/PSD - диаграмма структуры "целое - часть";
- STD - диаграмма переходов состояний.
- Общее описание проблемы - для сложных приложений может выполняться
итеративно и иерархически.
|
160
|
- Рекомендации по описанию:
- Использовать только декларативные предложения вида:
- Существительное - глагол;
- Существительное - глагол - дополнение (объект);
- Глагол - дополнение (объект);
- Обеспечить представление:
- всех нужных функций;
- основной информации и процессов;
- всех предложений на одном уровне абстракции, детализации и важности.
|
161
|
- 2.1. Перечень объектов,
- Выделить все существительные
- Переписать в отдельный список все глаголы, относящиеся к этим
существительным.
- Оценить каждое существительное из списка, является оно объектом или же
только атрибутом объекта.
- Отделить объекты, принадлежащие области решений, от объектов,
принадлежащих области проблем.
- Присвоить имя объектам, принадлежащим области решений.
- 2.2. Перечень процессов,
- Выделить все глаголы и переписать их в отдельный список.
- Оценить каждый глагол из списка, является ли он процессом.
- Отделить процессы, принадлежащие области решений, от процессов,
принадлежащих области проблем.
- Присвоить имя процессам, принадлежащим области решений.
- Приписать процессам объекты, если объект преобразуется процессом или
данные объекта считываются процессом.
- Оценить (по имеющейся процедуре) приписывание процессов объектам.
|
162
|
|
163
|
- Основные шаги ООП:
- Размещение объектов по поддоменам: пользователь, технические средства,
программное обеспечение или
данные.
- Разработка событийно-временных диаграмм для каждого множества
взаимодействующих процессов и их объектов.
- Определение обслуживающих объектов, которые необходимо использовать.
- Разработка диаграмм Буча.
- Определение передачи сообщений.
- Разработка диаграмм процессов.
- Разработка спецификаций модулей
|
164
|
|
165
|
- ОСНОВНЫЕ ТРЕБОВАНИЯ К СУБД:
- адекватность отображения ПО
- выполнение правил, по которым функционирует ПО
- контроль за состоянием БД
- анализ и оценка ситуаций в БД
- контроль используемых типов данных
- ДОПОЛНИТЕЛЬНЫЕ ТРЕБОВАНИЯ:
- многопользовательский режим
- многоплатформенность
- развитие БД
- многофункциональность
- поддержка общепринятых стандартов сетевого обмена
- поддержка стандартов межпрограммных интерфейсов
- управление распределенными БД
- СОСТАВ И ОРГАНИЗАЦИЯ СУБД:
- комплекс поддержки БД
- комплекс инструментальных средств
- комплекс сопровождения приложений
- комплекс обеспечения услуг
|
166
|
|
167
|
- Ядро СУБД.
- Программные системы, поддерживающие работу с распределенными БД.
- Работу в разнородной машинной среде.
- Сетевые конфигурации.
- Программное обеспечение параллельной работы.
- Реализация функций языка запросов.
|
168
|
- Комплекс инструментальных средств:
- программные системы для системных пользователей (системные аналитики,
системные программисты, аналитики-постановщики задач и др.)
- средства развития систем автоматизации
- (объектно-ориентированное проектирование и программирование)
- комплекс сопровождения приложений:
- пакеты прикладных программ в области
- финансовой деятельности,
- производства,
- кадрового обеспечения,
- подготовки и принятия решений.
|
169
|
- Комплекс услуг:
- предпродажные консультации,
- консультации по вопросам системной интеграции,
- техническое сопровождение систем,
- обучение специалистов.
|
170
|
- Основные функции ядра СУБД:
- управление данными во внешней памяти
- управление буферами оперативной
памяти
- управление процедурами
- управление правилами
- управление событиями
- управление транзакциями
- журнализация и восстановление БД
- защита данных
- поддержка единого интегрированного языка запросов: процедуры, правила,
события.
|
171
|
- Цели и задачи:
- централизованный контроль доступа к данным
- одновременное использование процедур
- снижение трафика сети
- поддержка целостности БД
|
172
|
- Правила (триггеры):
- обработка ситуаций при изменении состояний БД
- обеспечение целостности по ссылкам (внешние ключи)
- События:
- синхронизация процессов обработки
- обработка транзакций
- Свойства acid-транзакций
- атомарность
- согласованность
- изолированность
- долговечность
- Структура транзакций
- Обработка и фиксация транзакций
- Журнализация транзакций
|
173
|
|