Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Шпоры v.0.2.3.docx
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
108.32 Кб
Скачать

Сравнение 5 методов.

0. Наиболее трудным методом задания СП являются языки программирования. Сложность заключается в том, что языки программирования концентрируют внимание на деталях реализации, а потоки данных в DFD представляются абстрактно (их фактическая композиция определяется в словаре данных). Еще одна сложность — не в написании СП, а в их синхронизации и согласовании с DFD, поскольку при редактировании DFD должны корректироваться и СП.

1. Структурированный естественный язык применяется в случаях, когда детали СП известны не полностью. Он обеспечивает быстрое проектирование СП, прост в использовании, легко понимаем проектировщиками и программистами, а также конечным пользователем. К его недостаткам относятся отсутствие процедурных возможностей и неспособность к автоматической кодогенерации из-за наличия неоднозначностей.

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

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

10. Основные символы структурированного естественного языка и три его управляющие структуры: 1) последовательная конструкция; 2) конструкция выбора; 3) итерация. Соглашения, принятые при использовании структурированного естественного языка.

11. Таблица решений (матрица, отображающая множество входных условий в множество действий) — шаги построения. Таблица решений и дерево решений — рекомендации по предпочтениям.

12. Визуальные языки проектирования спецификаций — FLOW-формы и четыре вида их символов: последовательная обработка, условный выбор, case-выбор, циклы. Особенности диаграмм Насси-Шнейдермана.

13. Диаграммы «сущность-связь» (ERD) как базовые средства информационного моделирования. Нотации Чена и Баркера и их средства моделирования данных (наиболее популярные). Этапы построения информационной модели, включая нормализацию. ER-подход.

14. Шесть видов символов ERD в нотации Чена: 1) независимая сущность; 2) зависимая сущность; 3) ассоциированная сущность; 4) неограниченное (обязательное) отношение; 5) ограниченное (необязательное) отношение; 6) существенно-ограниченное отношение. Пять значений связи («0 или 1»,«0 или более»,«1»,«1 или более»,«p:q»). Три типа отношений: 1*1 (один к одному); 1*n (один к многим); n*m (многие к многим). Диаграммы атрибутов.

15. Категоризация сущностей. Общая сущность, сущность-категория. Декомпозиция сущности на категории. Узел-дискриминатор и диаграммы категоризации.

16. Нотация Баркера для ERD: графические особенности; подтип и супертип. Характеристики сущности и связи. Три этапа построения модели ERD: 1) Идентификация сущностей, их атрибутов, первичных и альтернативных ключей; 2) Идентификация отношений между сущностями и указание типов отношений; 3) Разрешение неспецифических отношений (т.е. типа n*m).

17. Нотация модели ERD – метод IDEF1. Независимы и зависимые сущности. Идентифицирующая и неидентифицирующая связь. Мощность связей. Создание и уровни логической модели данных в ERWin.

18. Концепции и методы нормализации; первая, вторая и третья нормальные формы нормализованных схем по Кодду (Codd); алгоритм приведения в 3НФ. Разрешение неспецифического отношения.

19. Модель требований (или логическая модель) системы, как совокупность множества взаимосвязанных диаграмм (IDEF0, DFD, IDEF3, ERD), текстов и словаря данных. Назначение модели требований — описание, что должна делать система без ссылок на то, как это делается.

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

21. Сущность и принципы объектно-ориентированного подхода (ООП). Отличие от структурного подхода. Концептуальная основа ООП. Основные понятия. Конечный результат.

22. Унифицированный язык моделирования UML. Цели разработки языка. Содержание стандарта UML версии l.1, принятый в 1997 г.

23. Диаграммы вариантов использования. Назначение, компоненты. Типы действующих лиц. Типы связей.

24. Диаграммы классов. Аспекты использования. Компоненты. Стереотипы классов. Типы отношений.

25. Диаграммы состояний. Их назначение, использование и компоненты.

26. Диаграммы взаимодействия объектов. Их назначение, использование и компоненты.

27. Диаграммы деятельностей. Их назначение, использование и компоненты.

28. Принципиальное различие, сравнение и взаимосвязь структурного и объектно-ориентированного подходов.

29. Концептуальные основы CASE (Computer-Aided Software/System Engineering)-технологий. Эволюция CASE как самостоятельной дисциплины в программотехнике.

30. Шесть этапов CASE-модели жизненного цикла программного продукта (прототипирование — проектирование спецификаций — контроль проекта — кодогенерация — системное тестирование — сопровождение) и ее отличия от пяти этапов традиционной модели (анализ — проектирование — кодирование — тестирование — сопровождение). Сравнение традиционной разработки программных проектов и разработки с применением CASE-технологий.

31. CASE-средства автоматизации методологий системного анализа и проектирования. Состав, структура и функциональные особенности современных CASE-средств. Архитектура CASE—пакета: 1) средства централизованного хранения всей информации о проектируемом программном обеспечении в течение всего жизненного цикла (репозиторий); 2) редактор диаграмм; 3) верификатор диаграмм; 4) администратор проекта; 5) документатор проекта.

32. Схема постановки и решения задачи: 1) формулирование задачи (1. формулирование цели, 2. описание исходных данных, 3. формулирование модели, 4. формулирование результата, 5. формулирование критерия оценки результата); 2) формализация задачи (1. формализация цели, 2. определение объектов и свойств, 3. определение способов вычисления свойств, 4. формирование таблицы «объекты-свойства», 5. формализация критерия оценки результата); 3) выбор способа решения задачи (1. определение возможности использования ЭВМ, 2. выбор математического аппарата для решения задачи, 3. определение алгоритмов решения, 4. формирование схемы обработки данных); 4) решение задачи (1. составление технологической схемы обработки, 2. прохождение технологической схемы на ЭВМ, 3. анализ результата с помощью критерия оценки); 5) интерпретация результата (1. согласование результата с моделью, 2. дальнейшее использование результата).

33. Классификация CASE-средств по типам (анализ и проектирование; проектирование баз данных и файлов; программирование; сопровождение и реинжениринг; окружение; управление проектом), по категориям (tools — вспомогательная программа; toolkit — пакет разработчика; workbench — инструментальное средство) и по уровням (Upper CASE; Middle CASE; Lower CASE).

34. Пример инструментального средства — пакет ERWin. Основные функции пакета и особенности используемых средств структурного системного анализа.

35. Пример инструментального средства — пакет AllFusion Process Modeler (BPWin). Основные функции пакета и особенности используемых средств CCA.

36. Технология проектирования: понятие, виды, классификация.

Технология проектирования ИС — совокупность методологий и средств проектирования ИС, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта ИС).

Наиболее часто при проектировании ИС используют технологии и методы системного проектирования (предварительное, концептуальное). Системное проектирование включает в себя следующие стадии:

1. Определение общих целей проектирования с формированием локальных (отдельных) целей разработки.

2. Формирование концепции системы (объекта исследования) и подготовки данных для создания модели объекта.

3. Разработки описания системы в виде структур объекта проектирования и построения функциональных подсистем объекта.

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

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

  • Крупные проекты. Обычно прибегают к помощи хорошо зарекомендовавших себя крупных компаний-интеграторов, в том числе консалтинговых и внедренческих организаций.

  • Средние проекты. Стараются обойтись своими силами и/или использовать готовые решения, которые стремятся адаптировать под конкретные требования организации-заказчика.

  • Малые проекты характеризуются использованием готовых решений и адаптацией их под конкретные условия использования.

Классификация CASE-технологий может проводиться по следующим признакам:

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

  • По графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями.

  • По степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных — репозиторием).

  • По типу и архитектуре вычислительной техники: ориентированные на ПК, ориентированные на ЛВС, ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа.

  • По режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов.

  • По типу ОС: работающие под управлением Windows 3.11 и выше; работающие под управлением UNIX; кроссплатформенные — работающие под управлением различных ОС (Windows, UNIX, OS/2 и др.).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]