 |
Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | |
Модель данных (ERD и ее подсхемы);
|
|
модель пользовательского интерфейса (выделение интерактивных и неинтерактивных функции с разделением процессов; диаграмма последовательности форм (FSD - Form Sequence Diagram) показывает формы приложения и их порядок. В 70-80-ые годы при проектировании для интерактивных подсистем строилась схема диалога пользователя, позволяющая «связать» все выходные и входные формы диалоговой системы для ее целостности, а для других подсистем выпускался альбом выходных форм. Отметить важность и полезность создания таких документов при проектированиимодели пользовательского интерфейса и сейчас.
На FSD фиксируется набор и структура вызовов экранных форм. Иерархия диаграмм FSD имеет на вершине главную форму приложения, реализующего подсистему. На втором уровне - формы реализации процессов нижнего уровня функциональной структуры из диаграмм SAD.
Фаза детального проектирования порождает модульную, т.е. реальную модель проектируемой прикладной системы. Этот процесс включает:
уточнение модели базы данных для генерации SQL-предложений далее;
уточнение структуры пользовательского интерфейса;
построение структурных схем для логики работы пользовательского интерфейса и модель бизнес-логики (Structure Charts Diagram - SCD) с привязкой их к формам.
Итоги детального проектирования:
модель процессов (структурные схемы интерактивных и неинтерактивных функций);
модель данных (определение в ERD всех нужных параметров для приложений);
модель пользовательского интерфейса (диаграмма последовательности форм или структура диалога (FSD), показывающая, какие формы появляются в приложении и в каком порядке, взаимосвязь между формами и структурными схемами, а также между каждой формой и одной или более сущностями в ERD).
Фаза реализации включает:
генерацию SQL-предложенийдля определения структуры целевой БД (таблицы, индексы, ограничения целостности);
уточнение структурных схем (SCD) и диаграмм последовательности форм (FSD) с последующей генерацией кода приложений.
После анализа потоков данных и взаимодействия процессов с хранилищами данных окончательно выделяют подсистемы (предварительно это фиксируется при формулировке требований в техническом задании). Выделение подсистем использует принципы функциональной связанности и минимизации информационной зависимости. На основании процессов и данных подсистемы на этапе разработки создают приложение, способное функционировать самостоятельно. Кроме того при группировке процессов и данных в подсистемы надо учитывать требования к конфигурированию продукта, данные на этапе анализа.
Выводы
Как видно из изложенного, между рассмотренными в этой и предыдущих главах методиками существует глубокая связь. Безусловно очевидно, что при разработке CASE – методик учитывался накопленный ранее опыт.
Действительно, построение функциональных подсистем осуществляется здесь путем деления наиболее общей функции на более частные(в предыдущей лекции для этих целей производилось деление цели).
ELM – матрица событий очевидный аналог информационных задач специалистов системы и разрабатывается с той же целью – для описания информационнго обеспечения системы. (информационных потоков и хранилищ информации).
Для FSD - Form Sequence Diagram), показывающих, какие формы появляются в приложении и в каком порядке. так же существует аналог - ранее строились схемы диалога – или схемы интерактивной работы пользователей. Назначение этих схем очевидно – чтобы не создать приложение, в котором можно заблудиться. Выше этот вопрос не рассматривался и не рассматривается здесь в виду того, что больше относится проектированию системы а не к анализу предметной области.
Таким образом можно сделать вывод о том, что CASE – методы являются некоторым мощным графическим инструментарием системного анализа, позволяющим построить информационную, функциональную и структурную модели системы.
Общая модель системы содержит информацию о функциональных особенностях данной системы, т.е о ее поведении. Кроме общей информации о воздействиях на систему и ее реакциях на окружающие объекты и системы, другой информации получить невозможно. В системном анализе созданы средства для дальнейшей конкретизации общей модели системы.
Процесс разработки адекватных моделей и применения требует общей методологии системного анализа и наличия изобразительных средств или языков для моделирования и документирования. Естественный язык негоден для этой цели из-за своей неоднозначности. Для моделирования разработаны теоретические методы на основе математических и логических средств, и предложены формальные и графические нотации, специфические для решаемых задач. Унификация любого языка моделирования увязана с методологией системного моделирования.
Сложность системы и ее модели рассматривается с разных точек зрения. Выделяют сложность структуры системы, характеристика которой - количество элементов системы и типы связей между ними. Если количество элементов больше не строго фиксированного порогового значения, то система называется сложной. Например, транспортная сеть современных мегаполисов вполне служит примером сложной системы.
Второй аспект сложности - сложность процесса функционирования системы, что вызвано непредсказуемым характером поведения системы и плохой формализуемостью функций выходов. Таковы современные операционные системы; им присуща сложность и структуры, и поведения.
Есть проблемы и в информационном отображении свойств системы. Так, информационная модель системы в нотации DFD - это диаграммы потоков данных, графически представленные соответствующей системой обозначений и используемые в некоторых CASE-средствах.
Главный недостаток этого подхода - отсутствие явных средств объектного представления моделей сложных систем и сложных алгоритмов обработки данных. На диаграммах DFD не указано времея выполнения отдельных процессов и передачи данных между процессами, поэтому модели систем параллельной обработки данных нельзя адекватно представить в нотации DFD. Еще одна трудность возникает при создании лингвистического обеспечения автоматизированных систем, так как оно не укладывается в графические рамки инструментария.
Как отмечалось выше, CASE - методология ориентирована на использование СУБД реляционного типа. Однако широко используются и СУБД других типов, например ADABAS. Необходимо отметить еще один нюанс - CASE инструментарий требует ежедневного использования – иначе навыки работы с программным продуктом исчезают и при эпизодическом его использовании приходится начинать заново его изучать, т.е. их эффективно использовать на предприятиях, имеющих большой и регулярный объем работы по разработке систем.
Все эти особенности методологии структурного системного анализа ограничили возможности ее широкого применения. Некоторые из этих трудностей устранены в методологии объектно–ориентированного подхода к анализу предметной области и средствах унифицированного языка моделирования.
Вопросы для самоконтроля
1. Суть структурного метода анализа предметной области, принципы, модели, порядок разработки.
2. Мeтодология SADT, область применения..
3. Функциональная модель мeтодологии SADT, правила построения.
4. Типы связей между структурами.
5. Моделирование потоков данных.
6. Накопители данных, их разновидности и использование при моделировании.
7. Понятие миниспецификации, критерии завершения построения иерархии диаграмм.
8. Методология DFD в нотациях Гейна-Сарсона и Йордана-Де Марко.
9. ER диграммы – метод проектирования баз данных.
10. Сущности и связи.
11. Подтипы и супертипы.
12. Правила построения ER-диаграмм:
13. Связь между различными типами диаграмм.
14. Инфологическое и даталогическое проектирование.
15. Информационная модель предметной области "Библиотека".
16. Область применения структурного метода анализа предметной области, ограничения.
Дата публикования: 2014-10-25; Прочитано: 658 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!
