- •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 Программирование компоненты “Оперативный учет”. Регистры. Регистр накопления. Регистр остатков. Измерения. Движения регистров. Примеры.
3. Жизненный цикл программного обеспечения ис
Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.
Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
В настоящее время известны и используются следующие модели жизненного цикла [7,8]:
- Каскадная модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
- Поэтапная модель с промежуточным контролем Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
- Спиральная модель (рис. 2.3.). На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).
На практике наибольшее распространение получили две основные модели жизненного цикла:
- каскадная модель (характерна для периода 1970-1985 гг.);
- спиральная модель (характерна для периода после 1986.г.).
Язык UML. История создания. Средства объектно-ориентированного проектирования.
объединял бы сильные стороны известных методов и обеспечивал наилучшую поддержку моделирования. Создание UML началось в октябре 1994 г.,
UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:
- является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС;
- содержит механизмы расширения и специализации базовых концепций языка.
UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.
UML включает внутренний набор средств моделирования, которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач. Пользователям языка предоставлены возможности:
- строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;
- добавлять при необходимости новые элементы и условные обозначения, если они не входят в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ограничения для конкретных предметных областей.
Объектно-ориентированные языки программированияпозволяют распространить требования строгой типизации на типы данных, определяемых программистом.
Объектно-ориентированный подход к проектированию программных изделий предполагает:
- проведение объектно-ориентированного анализа предметной области;
- объектно-ориентированное проектирование;
- разработку программного изделия с использованием объектно-ориентированного языка программирования.
StarUML - это проект с открытым кодом для разработки быстрых, гибких, расширяемых, функциональных и, главное, бесплатно доступных для любого пользователя платформ UML/MDA для 32-разрядных систем Windows. Цель проекта StartUML - в создании универсальной бесплатной платформы для моделирования, которая послужит аналогом для таких коммерческих проектов.
Open ModelSphere является большим инструментом моделирования для проектов матобеспечения любого размера. Вы можете Модели данных проектирования, Модели бизнес-процесса (BPM) и Модели UML
В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:
диаграммы классов, состояний, сценариев, модулей, процессов;
спецификации классов, объектов, атрибутов и операций;
заготовки текстов программ;
модель разрабатываемой программной системы.
Диаграммы вариантов использования. Актеры. Функции. Связи коммуникации, использования, расширения, обобщения. Пакеты.
Диаграммы вариантов использования описывают функциональное назначение системы или то, что система должна делать. Разработка диаграммы преследует следующие цели:
определить общие границы и контекст моделируемой предметной области;
сформулировать общие требования к функциональному поведению проектируемой системы;
разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;
подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актеру
Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей.
Между элементами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров актеров и вариантов использования.
В языке UML существует несколько стандартных видов отношений между актерами и вариантами использования:
ассоциации (association relationship);
расширения (extend relationship);
общения (generalization relationship);
включения (include relationship).Пакеты UML
Пакеты представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить диаграммы различного типа и назначения. В отличие от компонентов, существующих во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только во время разработки.
Диаграмма пакетов содержит пакеты классов и зависимости между ними. Зависимость между двумя пакетами имеет место в том случае, если изменения в определении одного элемента влекут за собой изменения в другом. По отношению к пакетам можно использовать механизм обобщения.