Вопросы для экзамена по курсу “Проектирование АСОИУ”/ 12/2006 (стр. 1 )

Вопросы для экзамена по курсу “Проектирование АСОИУ”/ 12/2006

1. Общая характеристика процесса проектирования АСОИУ. Цели и этапы разработки консалтинговых проектов. 2

2. Разработка системного проекта на основе стандарта ISO 12207. Основные процессы жизненного цикла программного обеспечения АСОИУ. 4

3. Модели жизненного цикла программного обеспечения АСОИУ. Подход RAD. 6

4. Структурный подход к проектированию информационной системы. Функциональная модель АСОИУ. Количественный анализ диаграмм IDEF0 и DFD. 9

5. Объектно-ориентированный подход к анализу и проектированию информационной системы. Унифицированный язык моделирования UML. 10

6. Моделирование бизнес-процессов спецификация требований на основе структурного подхода. 13

7. Моделирование бизнес-процессов спецификация требований на основе объектно-ориентированного подхода. Методика RUP. 14

8. Разработка модели защиты данных в АСОИУ. 15

9. Разработка пользовательского интерфейса. 16

10. Проектирование распределенной обработки данных. 17

11. Анализ и оценка производительности АСОИУ. 18

12. Управление проектом АСОИУ.. 19

13. Проектная документация АСОИУ. Требования ГОСТов к документации, содержание документации. 21

14. Инструментальные средства проектирования АСОИУ. 23

15. Типизация проектных решений АСОИУ. Использование коробочных продуктов и адаптируемых интегрированных систем. 24

16. Графические средства представления проектных решений АСОИУ (IDEF, DFD, UML, ERD и т. д.) 28

17. Распределенная обработка данных. 30

18. Системное проектирование Программных систем на основе стандартизации. 31

19. Стандартизированные показатели качества сложных программных систем.. 33

20. Понятие и виды CASE-средств. 34

21. Стандарты для информационных систем управления MRP, ERP, CSRP, CRM... 35

22. Аспекты внедрения ERP-систем. Стратегии и типы производства. 36

23. Стратегии производства и период поставки. 37

24. Стратегии производства и методы планирования. 38

25. Выбор типа управления производством.. 39

26. Эффективность внедрения корпоративной информационной системы. Традиционные финансовые методы.. 39

27. Эффективность внедрения корпоративной информационной системы. Качественные методы.. ..... 40

28. Эффективность внедрения корпоративной информационной системы. Вероятностные методы.. ..... 42

29. Характеристика рынка программного обеспечения по автоматизации деятельности организации. Состояние рынка программного обеспечения. 42

30. Характеристика рынка программного обеспечения по автоматизации деятельности организации. Основные участники рынка информационных и телекоммуникационных технологий. .... 43

31. Характеристика рынка программного обеспечения по автоматизации деятельности организации. Критерии выбора корпоративной информационной системы.. 44

32. Основные подходы внедрения КИС.. 45

33. Стратегии внедрения КИС на примере “Баан”. 47

34. Стратегии внедрения КИС на примере корпорации “Парус”. 48

1.  Общая характеристика процесса проектирования АСОИУ. Цели и этапы разработки консалтинговых проектов

Современные информационные технологии предоставляют широкий набор способов реализации АСОИУ, выбор которых осуществляется на основе требований со стороны предполагаемых пользователей, которые, как правило, изменяются в процессе разработки. Для теории принятия решений процесс проектирования системы – это процесс принятия проектно-конструкторских решений, направленных на получение версии системы, удовлетворяющей требования заказчика.

Под проектом будем понимать проектно-конструкторскую и технологическую документацию, в которой представлено описание проектных решений по созданию и эксплуатации системы в конкретной программно-технической среде.

Под проектированием системы понимается процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в соответствии с ГОСТом в проект АСОИУ. С этой точки зрения проектирование АСОИУ сводится к последовательной формализации проектных решений на различных стадиях жизненного цикла системы: предпроектного анализа требований, технического и рабочего проектирования, внедрения и эксплуатации АСОИУ.

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

Технология проектирования системы – это совокупность методологии и средств проектирования системы, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта системы).

В основе технологии проектирования лежит технологический процесс, который определяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий. Технологический процесс проектирования системы в целом делится на совокупность последовательно-параллельных, связанных и соподчиненных цепочек действий, каждое из которых может иметь свой предмет.

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

Суть содержания жизненного цикла разработки системы в различных подходах одинакова и сводится к выполнению следующих стадий:

Планирование и анализ требований (предпроектная стадия) – системный анализ. Исследование и анализ существующей системы, определение требований к создаваемой системе, оформление технико-экономического обоснования и технического задания на разработку системы.

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

Реализация проекта (рабочее проектирование, физическое проектирование, программирование). Разработка и настройка программ, наполнение баз данных, создание рабочих инструкций для персонала, оформление рабочего проекта.

Внедрение (тестирование, опытная эксплуатация). Комплексная отладка подсистем, обучение персонала, поэтапное внедрение системы в эксплуатацию, оформление акта о приемо-сдаточных испытаниях системы.

Эксплуатация системы (сопровождение, модернизация). Сбор рекламаций и статистики о функционировании системы, исправление ошибок и недоработок, оформление требований к модернизации системы и ее выполнение.

Консалтинг

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

Цели и этапы разработки консалтинговых проектов.

Основными целями разработки консалтинговых проектов являются:

-  представление деятельности предприятия и принятых в нем технологий в виде иерархии диаграмм, обеспечивающих наглядность и полноту их отображения;

-  формирование на основании анализа предложений по реорганизации организационно-управленческой структуры;

-  упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;

-  выработка рекомендаций по построению рациональных технологий работы подразделений предприятия и его взаимодействию с внешним миром;

-  анализ требований и проектирование спецификаций корпоративных информационных систем;

-  рекомендации и предложения по применимости и внедрению существующих систем управления предприятиями (прежде всего классов MRP - manufacturing resource planning и ERP - enterprise resource planning).

Структуру подхода к разработке консалтинговых проектов можно представить след. этапами.

1. Анализ первичных требований и планирование работ

Его основными задачами являются: анализ первичных бизнес-требований, предварительная экономическая оценка проекта, построение план-графика выполнения работ, создание и обучение совместной рабочей группы.

2. Проведение обследования деятельности предприятия

В рамках данного этапа осуществляется:

-  предварительное выявление требований, предъявляемых к будущей системе;

-  определение оргштатной и топологической структур предприятия;

-  определение перечня целевых задач (функций) предприятия;

-  анализ распределения функций по подразделениям и сотрудникам;

-  определение перечня применяемых на предприятии средств автоматизации.

3. Построение моделей деятельности предприятия

На данном этапе осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:

-  модели “как есть”;

-  модели “как должно быть”

4. Разработка системного проекта

Данный этап является первой фазой разработки собственно системы автоматизации, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?".

5. Разработка предложений по автоматизации предприятия

6. Разработка технического проекта

На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос: "Как (каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?". Этот этап разделяется на два подэтапа:

-  проектирование архитектуры системы;

-  детальное проектирование;

7. Последующие этапы

В случае разработки собственной системы последующие этапы являются традиционными: по спецификациям технического проекта осуществляется программирование модулей, их тестирование и отладка и последующая комплексация в автоматизированные рабочие места и в систему в целом. При этом схема интегрированной базы данных, как правило, генерируется автоматически на основании информационной модели.

2.  Разработка системного проекта на основе стандарта ISO 12207. Основные процессы жизненного цикла программного обеспечения АСОИУ.

Структура курсового проекта:

Введение

Применяемые стандарты

Оформление текста курсовой работы выполняется в соответствии с требованиями ГОСТ.

Глав. 1. Общая характеристика объекта автоматизации. Подразделения предприятия. Организационная структура IT службы предприятия. Функциональная структура АСУ.

Общая характеристика деятельности предприятия.

Глав. 2. Систематизация документооборота.

Глав. 3. Общая характеристика применяемых на предприятии тех. и программных средств.

Глав. 4. Разработка функциональной модели предприятия как есть.

Глав. 5. Как должно быть.

Глав. 6. Разработка технического задания.

Заключение

Актуальность, цель, задачи (выполненные). Перспективы развития данной работы. Литература.

Приложение. Оглавление приложений

Текст выступления. 3 плаката.

Структура технического задания.

1.1. Полное наименование системы, ее условное обозначение.

1.2. Шифр темы или шифр договора.

1.3. Наименование предприятия разработчика и заказчика и их реквизиты.

1.4. Перечень документов, на основании которых, создается данная информационная система.

1.5. Плановые сроки начала и окончания работы.

1.6. Сведения об источниках и порядке финансирования работ.

1.7. Порядок оформления и предъявление заказчику порядок работ по созданию проекта.

2. Назначение и цели создания (развития) системы

2.1. Вид автоматизируемой деятельности.

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

2.3. Наименование и требуемые значения показателей объекта (технических, технологических, производственно технологических, которые должны быть достигнуты при продвижении к цели).

3. Характеристика объекта автоматизации.

3.1. Краткие сведения об объекте авт.

3.2. Сведения об условии эксплуатации и окружающей среды.

4. Требования к системе.

4.1. Требования к системе в целом.

4.1.1. Требования к структуре и функционирования системы (перечень подсистем, уровни иерархии, степень детализации, способы информационного обмена, режимы функционирования, взаимодействие со смежными системами).

4.1.2. Требования к персоналу (численность пользователей, квалификация, режим работы, порядок подготовки).

4.1.3. Показатели назначения (степень приспасабливоемости системы к процесса в системе)

4.1.4. Требования к безопасности, эргономике, эксплуатации, ремонту, защите информации, патентной чистоте, по стандартизации и унификации.

4.2. Требования к функциям по под системам.

4.2.1. Перечень задач стоящих перед автоматизацией.

4.2.2. Временной регламент реализации каждой функции.

4.2.3. Требования к структуре выходных результатов.

4.2.4. Перечень и критерии отказов.

4.3. Требования к видам обеспечений.

4.3.1. Математическое обеспечение (состав и область применения мат. моделей типовых и разрабатываемых алгоритмов).

4.3.2. Информационное (состав, структура и организация данных, обмен данными между компонентами системами, совместимость между компонентами, используемые классификаторы шифраторы, СУБД, контроль данных и ведение информационных массивов).

4.3.3. Лингвистическое обеспечение (языки программирования, языки ввода вывода, системы кодирования).

4.3.4. Программное обеспечение. Независимость ПО от платформы. Качество программных средств, способов его контроля. Использование фондов алгоритмов и программ.

4.3.5. Метрологическое обеспечение.

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

4.3.7. Требования к методическому обеспечению (состав нормативно технической документации)

5. Состав и содержание работ по поддержанию систем (перечень стадий и этапов работ)

5.1. Перечень стадий и этапов работ.

5.2. Сроки исполнения

5.3. Состав организации исполнителей работ

5.4. Вид и порядок экспертизы технической документации

5.5. Программа обеспечения надежности

5.6. Программа метрологического обеспечения

6. Порядок контроля и приемки системы.

6.1. Виды, состав, объем и методы испытаний системы

6.2. Общие требования к приемке работ по стадиям

6.3. Статус приемной комиссии

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действии.

7.1. Преобразование входной информации к машиночитаемому виду

7.2. Изменения в объекте автоматизации

7.3. Сроки и порядок комплектования и обучения персонала

8. Требования к документированию.

8.1. Перечень подлежащих к разработке документов

8.2. Перечень документов на машинных носителях

9. Источники разработки. Это документы и информационные материалы, на основании которых разрабатывается ТЗ и информационная система.

Основные процессы ЖЦ

ISO 12-207

Жизненный цикл определяется как период времени который начинается с момента принятия решения о необходимости о его разработке проекта до полной утилизации. Основной нормативный документ определяющий ЖЦ ИС является стандарт ISO 12-207: 1995.

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

3.  Модели жизненного цикла программного обеспечения АСОИУ. Подход RAD.

Модель жизненного цикла - это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наибольшее распространение получили каскадная, а затем спиральная модели.

Рассмотрим каскадную и спиральную модели подробнее:

1. Каскадная модель

Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе. [4]

Каскадная модель разбивает процесс ЖЦ на пять этапов, выполняемых последовательно, один за другим:

Рисунок 5. Каскадная схема разработки ПО

Недостатки:

·  часто возникает потребность в возврате к предыдущим этапам для уточнения или пересмотра ранее принятых решений. В результате процесс принимает вид “модели с промежуточным контролем”

Рисунок 6. Каскадная схема с промежуточным контролем

·  существенное запаздывание с получением результатов,

·  требования к ИС "заморожены" в виде технического задания на все время ее создания, и, в случае неточного изложения требований или их изменения за время создания ПО, модель автоматизируемого объекта устаревает к моменту реализации.

2. Спиральная модель

Спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году. Делает упор на начальные этапы ЖЦ - анализ и проектирование. Реализуемость технических решений проверяется на этих этапах путем создания прототипов.

Рисунок 7. Спиральная модель жизненного цикла ПО

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

Главная задача при работе по спиральной модели - возможно быстрее показать пользователю работоспособный продукт, чтобы активизировать процесс уточнения и дополнения требований.

Сам Барри Боэм так характеризует спиральную модель разработки (используется с разрешения автора):

“Главное достижение спиральной модели состоит в том, что она предлагает спектр возможностей адаптации удачных аспектов существующих моделей процессов жизненного цикла. В то же время, ориентированный на риски подход позволяет избежать многих сложностей, присутствующих в этих моделях. В определенных ситуациях спиральная модель становится эквивалентной одной из существующих моделей. В других случаях она обеспечивает возможность наилучшего соединения существующих подходов в контексте данного проекта.

Спиральная модель обладает рядом преимуществ:

·  Модель уделяет специальное внимание раннему анализу возможностей повторного использования. Это обеспечивается, в первую очередь, в процессе идентификации и оценки альтернатив.

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

·  Модель предоставляет механизмы достижения необходимых параметров качества как составную часть процесса разработки программного продукта. Эти механизмы строятся на основе идентификации всех типов целей (требований) и ограничений на всех “циклах” спирали разработки. Например, ограничения по безопасности могут рассматриваться как риски на этапе специфицирования требований.

·  Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта. Это достигается явно определенными работами по анализу рисков, проверке различных характеристик создаваемого продукта (включая архитектуру, соответствие требованиям и т. п.) и подтверждение возможности двигаться дальше на каждом “цикле” процесса разработки.

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

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

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

Рисунок 8. Оригинальная спиральная модель жизненного цикла разработки по Боэму

Недостатки:

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

Переход с этапа на этап осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

3. Методология RAD

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений - RAD (Rapid Application Development).

Методология RAD предполагает:

·  маленький коллектив 2 – 10 чел.

·  короткий график от 2 до 6 мес.

·  повторяющийся цикл

Основные принципы методологии RAD

·  итерационность процесса разработки приложений;

·  необязательность полного завершения работ на каждом этапе;

·  максимальное вовлечение пользователей в разработку;

·  использование CASE - средств, обеспечивающих целостность проекта;

·  использование генераторов программного кода;

·  использование прототипирования для уточнения потребностей пользователей;

·  тестирование и развитие проекта одновременно с разработкой;

·  небольшие квалифицированные команды разработчиков;

·  четкое планирование и контроль на всех этапах работы.

Методология RAD дает хорошие результаты при выполнении относительно небольших проектов для конкретного заказчика.

Однако, ее нельзя использовать:

·  при разработке типовых систем, которые затем адаптируются к особенностям объектов внедрения;

·  для построения сложных расчетных программ, операционных систем, программ управления сложными объектами (системы АСУ ТП);

·  к приложениям, у которых интерфейсная часть не определяет логику работы системы;

·  к разработке систем, от которых зависит безопасность людей (например: управление самолетом или АЭС).

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

4.  Структурный подход к проектированию информационной системы. Функциональная модель АСОИУ. Количественный анализ диаграмм IDEF0 и DFD.

При структурном подходе как разновидности системного требуется синтезировать варианты системы из компонентов (блоков) и оценивать варианты при их частичном переборе с предварительным прогнозированием характеристик компонентов.

Структурно-функциональный подход к проектированию

Принципы:

– Разделяй и властвуй;

– иерархическое упорядочение;

– абстрагирование (выделение существенных аспектов и отличие их от несущественных);

– непротиворечивость (каждый элемент системы независим и не вступает в разнобой с остальными);

– структурирование данных.

Средства:

DFD – диаграмма потоков данных;

SADT – IDEF0, IDEF1, … – функциональные диаграммы;

ERD – диаграмма "сущность–связь".

Формирование требований к программному обеспечению:

SADT и DFD – AS-IS/TO-BE/ShouldBE

Стадия проектирования:

SADT (1973г. Дуглас Росс)

Основа метода – IDEF0 (Интегрированная компьютеризация производства)

SADT отображает функциональную структуру объекта, производимые им действия и связи между действиями.

1) Блоки и дуги – взаимодействие блоков друг с другом описываются посредством интерфейсных дуг.

2) Строгость и четкость – синтаксические правила, определяющие корректность диаграммы (на одной диаграмме д. б. 3-6 блоков, нумерация блоков, различие имен).

IDEF3

Аналогичен IDEF0, но менее требователен к синтаксису.

Существует понятие перекрестка – элемент который служит сигналом к началу нескольких работ при окончании нескольких, либо он показывает, что для начала одной работы надо ждать завершения нескольких работ.

Объект ссылки – выражает идею, которую нельзя связать со стрелкой, перекрестком или работой.

DFD

Методы Йордана и Гейна-Сэрсона.

1) Внешние сущности – материальный объект или физическое лицо, организующее (определяющие) источник/приемник информации;

2) Подсистемы (№ поля/имя поля/физическая реализации);

3) Процессы – преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом;

4) Накопители данных – абстрактное устройство для хранения информации, которое можно в любой момент поместить в накопитель и в любой момент извлечь;

5) Потоки данных – определяет информацию, передаваемую через некоторое соединение от источника данных к приемнику.

5.  Объектно-ориентированный подход к анализу и проектированию информационной системы. Унифицированный язык моделирования UML.

В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших название диаграмм. В терминах языка UML определены следующие виды диаграмм:

·  Диаграмма вариантов использования (use case diagram)

·  Диаграмма классов (class diagram)

·  Диаграммы поведения (behavior diagrams)

o  Диаграмма состояний (statechart diagram)

o  Диаграмма деятельности (activity diagram)

o  Диаграммы взаимодействия (interaction diagrams) 

§  Диаграмма последовательности (sequence diagram) 

§  Диаграмма кооперации (collaboration diagram) 

·  Диаграммы реализации (implementation diagrams)

o  Диаграмма компонентов (component diagram)

Диаграмма развертывания (deployment diagram)

Вариант использования

Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое название или имя в форме глагола с пояснительными словами (рис. 4.1).

Графическое обозначение варианта использования

Актеры

Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач.

Интерфейсы

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

В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:

·  Отношение ассоциации (association relationship) между актером и вариантом использования

·  Отношение расширения (extend relationship)

Так, если имеет место отношение расширения от варианта использования А к варианту использования В, то это означает, что свойства экземпляра варианта использования В могут быть дополнены благодаря наличию свойств у расширенного варианта использования А.

·  Отношение обобщения (generalization relationship)

·  Отношение включения (include relationship)

Пример построения диаграммы вариантов использования

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

Один из вариантов последующего уточнения диаграммы вариантов использования для примера рассматриваемой системы продажи

Класс

Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции (рис. 5.1). В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).

Рис. 5.1. Графическое изображение класса на диаграмме классов

Диаграмма состояний

Рис. 6.5. Диаграмма состояний для моделирования почтовой программы-клиента

Диаграмма деятельности (activity diagram)

6.  Моделирование бизнес-процессов спецификация требований на основе структурного подхода.

На сегодняшний день в программной инженерии существуют два основных подхода к разработке ПО ИС: функционально-модульный или структурный. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй, объектно-ориентированный подход использует объектную декомпозицию.

Итак, сущность структурного подхода к разработке ПО ЭИС заключается в его декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те — на задачи и так далее до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу вверх", от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.

Базовыми принципами структурного подхода являются:

-  принцип "разделяй и властвуй"

-  принцип иерархического упорядочения - принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

-  принцип абстрагирования – выделение существенных аспектов системы и отвлечение от несущественных;

-  принцип непротиворечивости — обоснованность и согласованность элементов системы;

-  принцип структурирования данных - данные должны быть структурированы и иерархически организованы.

В структурном подходе используются в основном две группы средств, описывающих функциональную структуру системы и отношения между данными.

-  DFD (Data Flow Diagrams) — диаграммы потоков данных;

-  SADT(Structured Analysis and Design Technique - метод структурного анализа и проектирования) — модели и соответствующие функциональные диаграммы; (IDEF0)

-  ERD (Entity-Relationship Diagrams) — диаграммы "сущность-связь".

Диаграммы потоков данных и диаграммы "сущность-связь" - наиболее часто используемые в CASE-средствах виды моделей.

7.  Моделирование бизнес-процессов спецификация требований на основе объектно-ориентированного подхода. Методика RUP.

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

Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются:

-  абстрагирование (abstraction);

-  инкапсуляция (encapsulation);

-  модульность (modularity);

-  иерархия (hierarchy).

Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:

-  типизация (typing);

-  параллелизм (concurrency),

-  устойчивость (persistence).

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