- •1. Общая характеристика процесса проектирования ис. Структура ис.
- •2. Классификация рынка ис.
- •3. Жизненный цикл программного обеспечения ис
- •6.Документирование потока событий. Основной поток. Альтернативный поток. Исключения. Примеры.
- •7. Диаграммы взаимодействия. Диаграммы последовательности. Объекты. Сообщения. Время жизни объекта. Рефлексивная связь. Примеры.
- •8.Диаграммы взаимодействия. Диаграммы кооперации. Примеры.
- •9.Диаграммы деятельностей. Потоки. Синхронизация, распараллеливание процессов. Примеры.
- •11.Отношения между классами. Ассоциация. Виды ассоциаций. Агрегация. Композиция. Наследование. Зависимость. Генерация программного кода. Примеры. Отношения между классами
- •13.Диаграммы компонентов. Модули. Включение классов в модули. Связи между компонентами. Примеры.
- •Диаграммы компонентов
- •14.Диаграммы размещений. Процессоры. Устройства. Примеры.
- •15.Каноническое проектирование ис. Гост 34.602-89. Стадии и этапы создания ис. Обследование. Техническое задание.
- •16.Методология моделирования предметной области. Структурная модель. Функциональная модель. Объектно-ориентированная модель. Синтетическая методика.
- •17.Исходные данные для проектирования. Процессные потоковые модели. Классификация процессов. Референтная модель бизнес-процесса. Проведение предпроектного обследования предприятий.
- •Выделение и классификация процессов
- •Проведение предпроектного обследования предприятий
- •Кодирование технико-экономической информации
- •Информационная база и способы ее организации
- •Моделирование данных
- •20.Разработка пользовательских интерфейсов. Типы интерфейсов. Сравнение интерфейсов.
- •21.Структура программных модулей.
- •22.Анализ и оценка производительности ис. Методы контроля проекта. Трудоемкость разработки программных средств.
- •Методы контроля проекта.
- •Трудоемкость разработки программных средств
- •23.Управление проектом ис. Управление производством программных средств. Управление разработкой программных средств. Организация коллективной разработки. Методы бригадной разработки.
- •Организация коллективной разработки
- •Методы бригадной разработки
- •24.Инструментальные средства проектирования ис.
- •Vantage Team Builder (Westmount I-case)
- •25.Типовое проектирование ис. Классы типового проектирования: элементные, подсистемные, объектные. Достоинства и недостатки.
- •26.Графические средства представления проектных решений.
- •27.Этапы проектирования ис с применением uml. Разработка модели бизнес-прецедентов
- •Разработка модели бизнес-объектов
- •Разработка концептуальной модели данных
- •Разработка требований к системе
- •Анализ требований и предварительное проектирование системы.
- •28.Тестирование ис. Белый ящик. Покрытие операторов. Покрытие решений. Покрытий условий. Примеры.
- •Разработка тестов методами белого ящика.
- •29.Эксплуатация ис. Этапы эксплуатации информационной системы
- •5.1. Приобретение имеющейся информации
- •5.2. Первоначальный сбор собственной информации
- •5.3. Обновление информации, ее анализ и распространение
- •34 Программирование компоненты “Оперативный учет”. Регистры. Регистр накопления. Регистр остатков. Измерения. Движения регистров. Примеры.
25.Типовое проектирование ис. Классы типового проектирования: элементные, подсистемные, объектные. Достоинства и недостатки.
Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение [19].
Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:
- элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);
- подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;
- объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.
Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.
26.Графические средства представления проектных решений.
CASE-средства обладают следующими основными особенностями :
имеют мощные графические средства для описания и документирования АСОИУ, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
осуществляют интеграцию отдельных компонент CASE-средств, обеспечивающую управляемость процессом разработки систем;
используют специальным образом организованное хранилище проектных метаданных (репозитория).
Современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых используются практически всеми ведущими западными фирмами.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную их ориентацию на те или иные процессы ЖЦ.
Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает следующее :
отдельные локальные средства, решающие небольшие автономные задачи (tools);
набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла систем (toolkit);
полностью интегрированные средства, поддерживающие весь ЖЦ систем и связанные общим репозиторием.
Помимо этого CASE-средства можно классифицировать по следующим признакам:
применяемым методологиям и моделям систем и БД;
степени интегрированности с СУБД;
доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств.
На сегодняшний день российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами: Vantage Team Builder (Westmount I-CASE), Designer/2000, Silverrun, ERwin+Bpwin, S-Designor, CASE-Аналитик, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE; VIS; RATIONAL ROSE.
DFD- диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования представляются в виде иерархии процессов, связанных потоками данных. Главная цель представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Внешняя сущность – материальный объект или физическое лицо, представляющее собой источник или приемник информации. Внешняя сущность обозначается квадратом, расположенным над диаграммой и бросающим на нее тень.
ERD – данная нотация используется в CASE средстве Oracle Designer.
Первый шаг моделирования – извлечение информации из интервью и выделение сущностей.
Второй шаг моделирования – идентификация связей. Связь это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным количеством экземпляров, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности родителя
Третий шаг – идентификация атрибута. Атрибут может быть либо обязательным, либо не обязательным
Возможный ключ – один или несколько атрибутов, чьи значенья однозначно определяют каждый экземпляр сущности.
UML - - приемник того поколения методов объектно-ориентированного анализа и проектирования, которые появились в конце 80-х и начале 90-х годов. Язык UML в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. UML содержит стандартный набор диаграмм и нотаций: диаграммы вариантов использования (для моделирования бизнес-процессов организации – требования к системе), классов (для моделирования статической структуры классов системы и связи между ними), поведения системы, взаимодействия (для моделирования процесса обмена сообщениями между объектами), состояния (для моделирования поведения объектов системы при переходе из одного состояния в другое), деятельности (для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельности ).
IDEF0 - диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм. Для того, чтобы указать положение любой диаграммы ли блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2.