
- •Особенности проектирования клиент-серверных ис.
- •2)Методы проектирования аис
- •Общие методы и технологии проектирования аис
- •3)Подготовка и проведения тестирования программного продукта Процессы жц верификация и валидация программ
- •7.2. Тестирование программ
- •7.2.1. Статические методы тестирования
- •7.2.2. Динамические методы тестирования
- •7.2.3. Функциональное тестирование
- •7.3. Инфраструктура процесса тестирования пс
- •7.3.1. Методы поиска ошибок в программах
- •4)Этапы проектирования ис
- •5)Состав и содержание работ на предпроектроной стадии создания проекта
- •6)Методы организации проведения обследования предметной области
- •7)Состав и содержание работ на стадии технико-рабочего проектирования
- •8)Состав и содержание работ на стадии внедрения проекта
- •9) Состав и содержание работ на стадиях эксплуатации и сопровождения проекта
- •10,11) Основные понятия классификации информации, Системы кодирования информации Основные понятия классификации технико-экономической информации
- •Правила классификации продукции
- •Кодирование технико-экономической информации
- •Понятие унифицированной системы документации
- •12)Единая система классификации и кодирования
- •В Единую систему классификации и кодирования (ескк) входят:
- •Различают два метода классификации:
- •К кодам предъявляются следующие требования:
- •Штриховое кодирование
- •13) Технология штрихового кодирования информации
- •Преимущества выбора штрихового кода
- •Одномерные символики
- •Двумерные символики
- •Системы штрихового кодирования информации
- •14) Понятие унифицированной системы документации
- •15)Проектирование первичных и результативных форм документов
- •16) Проектирование экранных форм документов
- •17)Понятие информационной базы и способы ее организации
- •18) Создание и ведение информационной базы
- •19) Основные понятия и методы защиты данных
- •20) Стандарты на создание систем защиты данных
- •21)Проектирование системы защиты данных
- •22)Основные понятия case-технологий case-технологии
- •23)Архитектура информационной системы
- •24)Функциональные подсистемы ис
- •25)Обеспечивающие подсистемы ис
- •26)Назначение и структура языка uml Общая характеристика языка uml
- •27)Методы системного анализа и моделирования
- •28)Основные пакеты моделей языка uml
- •29) Основные элементы пакетов языка uml Пакеты в языке uml
- •30) Состав пакета «элементы поведения»
- •31) Синтаксис и семантика языка uml Синтаксис и семантика основных объектов uml Классы
- •Диаграммы классов
- •Диаграммы использования
- •Диаграммы последовательностей
- •Кооперативные диаграммы
- •Диаграммы состояний
- •Диаграммы деятельности
- •Диаграммы компонентов
- •32) Диаграмма концептуального моделирования данных
- •Разработка модели бизнес-прецедентов
- •Разработка модели бизнес-объектов
- •Разработка концептуальной модели данных
- •Разработка требований к системе
- •Анализ требований и предварительное проектирование системы.
- •Разработка моделей базы данных и приложений
- •33) Диаграмма вариантов использования
- •Отношения на диаграмме вариантов использования
- •34) Диаграмма логического моделирования данных
- •35) Диаграммы классов Диаграммы классов uml. Логическое моделирование
- •36)Диаграммы состояний
- •37)Диаграмма физического моделирования данных
- •38)Диаграмма деятельности
- •40)Диаграммы кооперации Кооперации (collaborations)
- •39)Диаграмма деятельности
- •41)Диаграмма компонентов Диаграмма компонентов (component diagram)
- •Интерфейсы
- •Зависимости
- •Рекомендации по построению диаграммы компонентов
- •42)Диаграммы развертывания
- •43) Средства реализации case-технологий
Разработка модели бизнес-объектов
Следующим этапом проектирования ИС является разработка модели бизнес-объектов, которая показывает выполнение бизнес-процессов организации ее внутренними исполнителями. Основными компонентами моделей бизнес-объектов являются внешние и внутренние исполнители, а также бизнес-сущности, отображающие все, что используют внутренние исполнители для реализации бизнес-процессов. Пример модели бизнес-объектов для прецедента " Ответ на запрос " приведен на рис. 12.5.
Рис. 12.5. Модель бизнес-объектов прецедента "Ответ на запрос"
В этой диаграмме появилось новое действующее лицо – отправитель запроса. На самом деле с запросом о состоянии пациента могут обращаться в систему многие из действующих лиц: юрист, страховая компания, технический персонал и даже сам пациент. Таким образом, понятие " Отправитель запроса " служит для обобщенного представления всех этих действующих лиц при описании прецедента "Ответ на запрос " (рис. 12.6). " Отправитель запроса " становится суперклассом по отношению к обобщаемым понятиям (подклассам).
Рис. 12.6. Обобщение классов
Для детального описания выполнения бизнес-процессов обычно используются диаграммы последовательностей (рис. 12.7).
Рис. 12.7. Диаграмма последовательностей для прецедента "Ответ на запрос"
Основными элементами диаграммы последовательностей являются обозначения объектов (прямоугольники), вертикальные линии, отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами.
Результатом этого этапа являются согласованные с заказчиком и достаточно подробные описания действий специалистов организации, внедряющей ИС, необходимые для обеспечения исполнения ее функций.
Разработка концептуальной модели данных
Затем на основе информации, выявленной на этапах бизнес-моделирования, выполняется разработка концептуальной модели данных, которые будут использоваться в разрабатываемой системе. На рис. 12.8 представлена в виде диаграммы классов модель данных для объекта " Клинические записи ".
Рис. 12.8. Концептуальная модель данных
Модель показывает, что клинические записи включают (агрегируют) ряд блоков. При этом " минимальный набор данных " и " план лечения" могут быть включены в каждую клиническую запись в единственном экземпляре, а блоки " результаты анализов ", " предписания врача", " ход лечения " могут повторяться неограниченное число раз.
Архив состоит из множества клинических записей (агрегирует клинические записи), но может быть и пустым.
Поскольку пациент может предварительно проходить лечение в других учреждениях, или несколько раз проходить лечение в центре, появляются дополнительные разновидности (подклассы) клинических записей: внешние, старые внутренние, новые внутренние.
Этот этап завершает процедуры бизнес-моделирования и позволяет представить команде проектировщиков в едином формате ту информацию, которая будет необходима для создания системы. Разработанные диаграммы являются отправной точкой в процессахпроектирования баз данных и приложений системы, обеспечивают согласованность действий бизнес-аналитиков и разработчиков в процессе дальнейшей работы над системой. Эти диаграммы, конечно же, будут претерпевать изменения в процессе последующего проектирования, однако эти изменения будут фиксироваться в формате, уже привычном для всей команды разработчиков, и будут автоматически отражаться в последующих моделях.