Архитектура информационных систем

Размещено на http://www.allbest.ru/

Вопросы к зачету с оценкой

1. Назначение и виды ИС

2. Основные составляющие корпоративных информационных систем

3. Соотношение между составляющими информационной системы

4. Классификация информационных систем

5. Состав функциональных и обеспечивающих подсистем ИС

6. Архитектура файл-сервер

7. Архитектура клиент сервер

8. Многоуровневая архитектура

9. Интернет/ интернет технологии

10. Назначение и виды информационно-коммуникационных технологий (ИКТ)

11. Модели и процессы жизненного цикла ИС

12. Жизненный цикл информационных систем

13. Процессы, протекающие на протяжении жизненного цикла информационной системы

14. Структура жизненного цикла информационной системы

15. Преимущества и недостатки каскадной модели жизненного цикла.

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

17. Типы данных. Примитивные, ссылочные

18. Типы данных. Целочисленные

19. Типы данных. С плавающей точкой

20. Типы данных. Символьный, строковый, логический

21. Преобразование примитивных типов. Автоматическое и ручное

22. Преобразование примитивных типов. Сужающее и расширяющее

23. Преобразование ссылочных типов данных

24. Методология IDEF. Виды IDEF-моделей

25. Методология SADT.

26. Методология UML. UML-диаграммы

27. Автоматизация процессов разработки ИС.

28. Средства автоматизации разработки программного обеспечения

29. CASE-технология: назначение, состав и ключевые возможности

30. CASE-средства: назначение и выполняемые функции

31. Репозиторий. Роль репозитория в автоматизации процессов разработки ИС.

32. Подходы к автоматизации процессов разработки ИС

33. Структурный подход (информационные, функциональные, структурные модели).

34. Объектно-ориентированный подход

35. CASE-технологии

36. Средства, реализующие CASE-технологии

37. Характеристика современных CASE-средств

38. Моделирование информационных систем

39. Виды моделей.

40. Объектно-ориентированный анализ и проектирование.

41. Технологии, языки и средства моделирования.

42. Язык унифицированного моделирования UML

43. Диаграммы языка UML: структурные диаграммы, диаграммы поведения, диаграммы взаимодействия.

44. Инструментальные средства моделирования ИС

45. Применение UML при проектировании ИС

46. Методика разработки функциональных моделей в среде IDEF0.

47. Информационное моделирование в методике IDEF1X

48. Средства разработки программного обеспечения ИС

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

50. Интегрированные среды разработки

51. Современные средства разработки ПО

52. Методология быстрой разработки приложений RAD

53. Технология визуального программирования

54. Автоматическая генерация программного кода

55. Применение RAD и визуального программирования для прототипирования клиентских приложений ИС

Ответы на вопросы к зачёту

1. Назначение и виды ИС

Информационная система представляет собой совокупность таких компонентов как информация, процедуры, персонал, аппаратное и программное обеспечение, объединенных регулируемыми взаимоотношениями для формирования организации как единого целого и обеспечения её целенаправленной деятельности.

Виды ИС:

* структурированная система

* неструктурированная система

* экспертная система

2. Основные составляющие корпоративных информационных систем

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

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

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

3. Соотношение между составляющими информационной системы

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

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

4. Классификация информационных систем

информационный коммуникационный технология

Информационные системы классифицируют по следующим признакам:

* по признаку структурированности задач- структурированные (формализуемые задачи)

- неструктурированные (неформализуемые) задачи

- частично структурированные задачи

* по характеру представления и логической организации хранимой информации

- фактографические ИС

- документальные ИС

- геоинформационные ИС

. по выполняемым функциям и решаемым задачам

- справочные ИС

- информационно-поисковые ИС

- расчетные ИС

- технологические ИС

* по масштабу и интеграции компонент

- локальный АРМ (автоматизированное рабочее место)

- комплекс информационно и функционально связанных АРМ

- компьютерная сеть АРМ на единой информационной базе

- корпоративная информационная система (КИС)

* по характеру обработки информации на различных уровнях управления

предприятием

- системы обработки данных

- ИС управления

- системы поддержки принятия решений

* по уровням управления

- ИС оперативного(операционного) уровня

- ИС специалистов

- ИС для менеджеров среднего звена

- стратегические ИС

* классификация ИС по функциональному признаку

- производственные системы

- системы маркетинга

- финансовые и учетные системы

- системы кадров

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

. по характеру использования информации- информационно-поисковые системы

- информационно-решающие системы

- гипертекстовые системы

. по сфере применения

- ИС организационного управления

- ИС управления технологическими процессами

- ИС автоматизированного проектирования

- корпоративные ИС

* укрупненная классификация систем, предназначенных для

автоматизации различных видов хозяйственного учета

- локальные системы

- средние интегрированные системы

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

. по степени автоматизации

- ручные

- автоматические

- автоматизированные

. по сфере применения

- ИС организационного управления

- ИС управления технологическими процессами (ТП)

- ИС автоматизированного проектирования (САПР)

- обучающие ИС

- корпоративные ИС

- интегрированные ИС

* по степени распределенности ИС

- настольные

- распределенные (файл-серверные и клиент-серверные ИС)

5. Состав функциональных и обеспечивающих подсистем ИС

Функциональная часть определяет назначение ИС, ее основные цели, задачи, функции и представляет собой модель системы управления экономическим объектом. Функциональная часть включает функциональные подсистемы, представляющие собой комплекс задач управления этим объектом.

Типовые функциональные подсистемы:

* по управлению отдельными ресурсами

* по функциональному признаку

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

Среди обеспечивающих подсистем выделяют:

* информационное обеспечение

* математическое обеспечение

* организационное обеспечение

* эргономическое обеспечение

* техническое обеспечение

* программное обеспечение

* правовое обеспечение

6. Архитектура файл-сервер

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

Достоинства такой архитектуры:

* многопользовательский режим работы c данными

* удобство централизованного управления доступом

* низкая стоимость разработки

* высокая скорость разработки

* невысокая стоимость обновления и изменения ПО

Недостатки:

* проблемы многопользовательской работы с данными:

* последовательный доступ

* отсутствие гарантии целостности

* низкая производительность (зависит от производительности сети, сервера, клиента)

* плохая возможность подключения новых клиентов

* ненадежность системы

7. Архитектура клиент-сервер

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

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

Клиентская часть приложения взаимодействует с клиентской частью ПО управления БД, которая, фактически, является индивидуальным представителем СУБД для приложения.

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

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

Преимуществами данной архитектуры являются:

* возможность распространить функции вычислительной системы между несколькими независимыми компьютерами в сети

* все данные хранятся на сервере. В основном он защищен намного лучше

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

* поддержка многопользовательской работы

* гарантия целостности данных

Недостатки:

* неработоспособность сервера может сделать неработоспособной всю вычислительную сеть

* администрирование данной системы требует квалифицированного профессионала

* высокая стоимость оборудования

* бизнес-логика приложений осталась в клиентском ПО

8. Многоуровневая архитектура

Многоуровневая архитектура клиент-сервер - одна из разновидностей архитектуры клиент-сервер, в которой функция обработки данных вынесена на один/несколько отдельных серверов, что позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов. Среди многоуровневой архитектуры наиболее распространена трехуровневая архитектура (трехзвенная архитектура), которая предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят - «тонкий клиент» или терминал), подключенное к серверу приложений и далее подключен к серверу базы данных.

Плюсы данной архитектуры:

* клиентское ПО не нуждается в администрировании

* масштабируемость

* конфигурируемость

* высокая безопасность

* высокая надежность

* низкие требования к скорости канала (сети) между терминалами и сервером приложений

* низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости.

Минусы:

* растет сложность серверной части и, как следствие, затраты на

* администрирования и обслуживание

* более высокая сложность создания приложений

* сложнее в разворачивании и администрировании

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

* высокие требования к скорости канала (сети) между сервером данных и серверами приложений.

9. Интернет/ интернет технологии

Интернет-технологии - это разного рода технологии и сервисы, которые позволяют осуществляет всю деятельность в компьютерной сети Интернет. Если выразиться проще, интернет-технологии - это всё, с чем мы работаем в Интернете. В первую очередь - это всевозможные сайты, форумы, блоги… Также к интернет-технологиям относятся программное обеспечение и всевозможные механизмы для работы с «всемирной паутиной». В основе Интернет-технологий лежат гипертексты (тексты с гиперссылками на другие гипертексты) и сайты, размещаемые в глобальной сети Интернет либо в локальных компьютерных сетях.

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

Интернет-технологии представляют собой сложную систему взаимодействия двух составляющих: физической и логической.

Физическая составляющая Интернет - технологий включает в себя:

* Сеть Интернет

- Протоколы TCP/IP

- Иерархия доменных имен сети Интернет

- Опорная сеть Интернета. Маршрутизация

. Программное обеспечение в Интернете

- Сетевые операционные системы

- Специальное программное обеспечение для соединения с Интернетом

- Прикладные протоколы

* Компьютеры (серверы и клиенты) в Интернете

- Серверы электронной почты

- Веб - серверы

- FTP-серверы

- Серверы телеконференций

- Серверы мгновенных сообщений

* Цифровые линии связи

- Выбор провайдера. Подключение к Интернету

* Доступ в Интернет

- Соединение сетевой карты с локальной сетью

- Кабельные системы Ethernet

* Удаленный доступ к глобальным сетям

- Доступ «компьютер - сеть»

- Доступ «сеть-сеть»

10. Назначение и виды информационно-коммуникационных технологий (ИКТ)

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

Виды ИКТ:

* по предметной деятельности:

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

- технологии управления технологическими процессами (управление технологическими устройствами, станками, автоматическими линиями)

- технологии автоматизированного проектирования (моделирование, программирование)

- образовательные технологии (оптимизация образовательного процесса).

* в сфере образования:

- программные продукты, которые обеспечивают качество разработки и эргономики (к примеру, офисные программы, позволяющие подготовиться к урокам, лекциям, семинарам)

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

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

11. Модели и процессы жизненного цикла ИС

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

* каскадная

* инкрементах

* спиральная

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

* формирование требований

* анализ требований

* проектирование

* реализация

* тестирование

* эксплуатация

12. Жизненный цикл информационных систем

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

13. Процессы, протекающие на протяжении жизненного цикла информационной системы

Согласно стандарту, ISO/IEC 12207 структура жизненного цикла основывается на трех группах процессов:

* основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение)

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

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

14. Структура жизненного цикла информационной системы

Согласно стандарту, ISO/IEC 12207 структура жизненного цикла основывается на трех группах процессов:

* основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение)

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

* организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).

15. Преимущества и недостатки каскадной модели жизненного цикла

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

Преимущества:

* Последовательное выполнение этапов проекта в строгом фиксированном порядке

* Позволяет оценивать качество продукта на каждом этапе

Недостатки:

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

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

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

Спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков (используется с разрешения автора):

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.3. Реализация несоответствующей функциональности.

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

5.“Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

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

8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9. Недостаточная производительность получаемой системы.

10. “Разрыв” в квалификации специалистов разных областей знаний. Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде. Сам Барри Боэм так характеризует спиральную модель разработки (используется с разрешения автора): “Главное достижение спиральной модели состоит в том, что она предлагает спектр возможностей адаптации удачных аспектов существующих моделей процессов жизненного цикла. В то же время, ориентированный на риски подход позволяет избежать многих сложностей, присутствующих в этих моделях. В определенных ситуациях спиральная модель становится эквивалентной одной из существующих моделей. В других случаях она обеспечивает возможность наилучшего соединения существующих подходов в контексте данного проекта.

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

* Модель уделяет специальное внимание раннему анализу возможностей повторного использования.

* Модель предполагает возможность эволюции жизненного цикла, развитие и изменение программного продукта.

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

* Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта.

* Модель позволяет контролировать источники проектных работ и соответствующих затрат.

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

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

17. Типы данных. Примитивные, ссылочные.

Ссылочные типы являются объектами. Примитивные типы -это скалярные величины. В языках программирования, не являющихся объектно-ориентированными, примитивные типы называют простыми типами. Примитивные типы данных - это базовые типы данных языка программирования. Их ключевая особенность в том, что данные в них, в отличие от ссылочных типов, располагаются непосредственно [“в переменной”.] на участке памяти компьютера в котором находится переменная.

Целочисленный тип данных. Обычно объявляется ключевым словом int или integer. Переменные данного типа могут принимать только целочисленные значения.

18. Типы данных. Целочисленные

Целочисленный тип данных - это тип, переменные которого могут содержать только целые числа (без дробной части, например: -2, -1, 0, 1, 2). Переменная с n-ным количеством бит может хранить 2n возможных значений. Но что это за значения? Это значения, которые находятся в диапазоне. Диапазон - это значения от и до, которые может хранить определенный тип данных. Диапазон целочисленной переменной определяется двумя факторами: её размером (измеряется в битах) и её знаком (который может быть signed или unsigned).

19. Типы данных. С плавающей точкой

Тип данных с плавающей точкой - «floating point». Переменная такого типа может хранить любые действительные дробные значения, например: 4320.0, -3.33 или 0.01226. Почему точка «плавающая»? Дело в том, что точка/запятая перемещается («плавает») между цифрами, разделяя целую и дробную части значения. Есть три типа данных с плавающей точкой: float, double и long double. Язык C++ определяет только их минимальный размер (как и с целочисленными типами). Типы данных с плавающей точкой всегда являются signed (т.е. могут хранить как положительные, так и отрицательные числа). Если нужно использовать целое число с переменного типа с плавающей точкой, то тогда после этого числа нужно поставить разделительную точку и нуль. Это позволяет различать переменные целочисленных типов от переменных типов с плавающей запятой.

20. Типы данных. Символьный, строковый, логический

Простые данные можно разделить на

1. целочисленные,

2. вещественные,

3. символьные,

4. логические.

Целочисленные данные

Целочисленные данные могут быть представлены в знаковой и беззнаковой формы. Беззнаковые целые числа представляются в виде последовательности битов в диапазоне от 0 до 2n-1, где n-количество занимаемых битов. Знаковые целые числа представляются в диапазоне -2n-1…+2n-1-1. При этом старший бит данного отводится под знак числа (0 соответствует положительному числу, 1 - отрицательному).

Вещественные данные

Вещественный тип предназначен для представления действительных чисел. Вещественные числа представляются в разрядной сетке машины в нормированной форме. К ним относятся float, double и long double.

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

В двоичной системе счисления значащий разряд, стоящий перед разделителем целой и дробной части, может быть равен только 1. В случае если число нельзя представить в нормированной форме (например, число 0), значащий разряд перед разделителем целой и дробной части равен 0. Значащие разряды числа, стоящие в нормированной форме после разделителя целой и дробной части, называются мантиссой числа.

21. Преобразование примитивных типов. Автоматическое и ручное

Для автоматического преобразования типа должно выполняться два условия:

* оба типа должны быть совместимы

* длина целевого типа должна быть больше длины исходного типа

В этом случае происходит преобразование с расширением. Например, тип данных int всегда достаточно велик, чтобы хранить все допустимые значения типа byte, поэтому никакие операторы явного приведения типов в данном случае не требуются. С точки зрения расширяющего преобразования числовые типы данных, в том числе целочисленные и с плавающей точкой, совместимы друг с другом. В то же время не существует автоматических преобразований числовых типов в тип char или boolean. Типы char и boolean также не совместимы друг с другом.

Стоит немного пояснить почему, к примеру тип byte не преобразуется автоматически (не явно) в тип char, хотя тип byte имеет ширину 8 бит, а char - 16. То же самое касается и преобразования типа short в char. Это происходит потому, что byte и short знаковые типы данных, а char беззнаковый. Поэтому в данном случае требуется использовать явное приведение типов, поскольку компилятору надо явно указать, что вы знаете чего хотите и как будет обрабатываться знаковый бит типов byte и short при преобразовании к типу char. Поведение величины типа char в большинстве случаев совпадает с поведением величины целого типа, следовательно, значение типа char можно использовать везде, где требуются значения int или long. Однако напомним, что тип char не имеет знака, поэтому он ведет себя отлично от типа short, несмотря на то что диапазон обоих типов равен 16 бит.

22. Преобразование примитивных типов. Сужающее и расширяющее

Для простых типов расширение означает, что осуществляется переход от менее емкого типа к более емкому. Например, от типа byte (длина 1 байт) к типу int (длина 4 байта). Такие преобразования безопасны в том смысле, что новый тип всегда гарантированно вмещает в себя все данные, которые хранились в старом типе, и таким образом не происходит потери данных. Обратите внимание, что нельзя провести преобразование к типу char от типов меньшей или равной длины ( byte, short ), или, наоборот, к short от char без потери данных. Это связано с тем, что char, в отличие от остальных целочисленных типов, является беззнаковым. Тем не менее, следует помнить, что даже при расширении данные всё-таки могут быть в особых случаях искажены. Они уже рассматривались в предыдущей лекции, это приведение значений int к типу float и приведение значений типа long к типу float или double. Хотя эти дробные типы вмещают гораздо большие числа, чем соответствующие целые, но у них меньше значащих разрядов.

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

23. Преобразование ссылочных типов данных

Преобразование объектных типов лучше всего иллюстрируется с помощью дерева наследования. Рассмотрим небольшой пример наследования:

// Объявляем класс Parent

class Parent {

int x;

}

// Объявляем класс Child и наследуем

// его от класса Parent

class Child extends Parent {

int y;

}

// Объявляем второго наследника

// класса Parent - класс Child2

class Child2 extends Parent {

int z;

В каждом классе объявлено поле с уникальным именем. Будем рассматривать это поле как пример набора уникальных свойств, присущих некоторому объектному типу. Три объявленных класса могут порождать три вида объектов. Объекты класса Parent обладают только одним полем x, а значит, только ссылки типа Parent могут ссылаться на такие объекты. Объекты класса Child обладают полем y и полем x, полученным по наследству от класса Parent. Стало быть, на такие объекты могут указывать ссылки типа Child или Parent. Второй случай уже иллюстрировался следующим примером: Parent p = new Child();

Обратите внимание, что с помощью такой ссылки p можно обращаться лишь к полю x созданного объекта. Поле y недоступно, так как компилятор, проверяя корректность выражения p.y, не может предугадать, что ссылка p будет указывать на объект типа Child во время исполнения программы. Он анализирует лишь тип самой переменной, а она объявлена как Parent, но в этом классе нет поля y, что и вызовет ошибку компиляции. Аналогично, объекты класса Child2 обладают полем z и полем x, полученным по наследству от класса Parent. Значит, на такие объекты могут указывать ссылки типа Child2 или Parent. Таким образом, ссылки типа Parent могут указывать на объект любого из трех рассматриваемых типов, а ссылки типа Child и Child2 - только на объекты точно такого же типа. Теперь можно перейти к преобразованию ссылочных типов на основе такого дерева наследования. Расширение означает переход от более конкретного типа к менее конкретному, т.е. переход от детей к родителям. В нашем примере преобразование от любого наследника ( Child, Child2 ) к родителю ( Parent ) есть расширение, переход к более общему типу. Подобно случаю с примитивными типами, этот переход производится самой JVM при необходимости и незаметен для разработчика, то есть не требует никаких дополнительных усилий, так как он всегда проходит успешно: всегда можно обращаться к объекту, порожденному от наследника, по типу его родителя.

Parent p1=new Child();

Parent p2=new Child2();

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

24. Методология IDEF. Виды IDEF-моделей

Методология IDEF. Виды IDEF-моделей. IDEF - методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

IDEF - методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности - ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами - участниками программы ICAM (отсюда название: Icam DEFinition - IDEF другой вариант - Integrated DEFinition). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес- процессов (к слову сказать, он активно применяется и в российских госструктурах, например, в Государственной Налоговой Инспекции). Более того, собственно с широким применением IDEF (и предшествующей методологии - SADT) и связано возникновение основных идей популярного ныне понятия - BPR (бизнес-процесс реинжиниринг). Семейство стандартов В настоящий момент к семейству IDEF можно отнести следующие стандарты:

IDEF0 - Function Modeling - методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique);

IDEF1 - Information Modeling - методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

IDEF1X (IDEF1 Extended) - Data Modeling - методология построения реляционных структур (баз данных), относится к типу методологий «Сущностьвзаимосвязь» (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF2 - Simulation Model Design - методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN - Color Petri Nets);

IDEF3 - Process Description Capture - Документирование технологических процессов, IDEF3 - методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;

IDEF4 - Object-Oriented Design - методология построения объектноориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

IDEF5 - Ontology Description Capture - Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

IDEF6 - Design Rationale Capture - Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF7 - Information System Auditing - Аудит информационных систем.

Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF8 - User Interface Modeling - Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);

IDEF9 - Scenario-Driven IS Design (Business Constraint Discovery method) -- Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений, в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии, уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение

IDEF10 - Implementation Architecture Modeling - Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF11 - Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF12 - Organization Modeling - Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF13 - Three Schema Mapping Design - Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;

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

25. Методология SADT

SADT (акроним от англ. Structured Analysis and Design Technique) - методология структурного анализа и проектирования, интегрирующая процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком. Процесс моделирования может быть разделен на несколько этапов: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования. Этот процесс хорошо отлажен, потому что при разработке проекта специалисты выполняют конкретные обязанности, а библиотекарь обеспечивает своевременный обмен информацией.

26. Методология UML. UML-диаграммы

Унифицированный язык моделирования (Unified Modeling Language - UML) - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация.

Структурные диаграммы:

1. Диаграмма классов

2. Диаграмма компонентов

3. Композитной/составной структуры

4. Диаграмма кооперации (UML2.0)

5. Диаграмма развёртывания

6. Диаграмма объектов

7. Диаграмма пакетов

8. Диаграмма профилей (UML2.2)

27. Автоматизация процессов разработки ИС

Аббревиатура CASE (Computer-Aided Software Engineering - автоматизированная разработка программного обеспечения) обозначает специальный тип программного обеспечения, предназначенного для поддержки таких процессов создания ПО, как разработка требований, проектирование, кодирование и тестирование программ. Поэтому к CASE-средствам относятся редакторы проектов, словари данных, компиляторы, отладчики, средства построения систем и т.п. CASE-средства предлагают поддержку процесса создания ПО путем автоматизации некоторых этапов разработки, а также создания и представления информации, необходимой для разработки. В настоящее время подходящие CASE-технологии существуют для большинства процессов, выполняемых в ходе разработки ПО. Это ведет к улучшению качества создаваемых программ и повышению производительности труда разработчиков программного обеспечения. Уже сложилась развитая индустрия CASE-средств, а круг поставщиков и разработчиков этих программных продуктов очень широк.

* CASE-средство Silverrun;

* средство разработки приложений JAM;

* мост Silverrun-RDM JAM;* комплекс средств тестирования QA;

* менеджер транзакций Tuxedo;

* комплекс средств планирования и управления проектом SE

Companion;

* комплекс средств конфигурационного управления PVCS;

* объектно-ориентированное CASE-средство Rational Rose;

* средство документирования SoDA.

28. Средства автоматизации разработки программного обеспечения

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

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

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

Пакет инструментальных CASE-средств:

1. Редакторы диаграмм предназначены для создания диаграмм потоков данных, иерархий объектов, диаграмм «сущность-связь». Эти редакторы не только имеют средства рисования, но и поддерживают различные типы объектов, используемых в диаграммах.

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

3. Центральный репозиторий позволяет проектировщику найти нужный проект и соответствующую ему проектную информацию.

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

5. Средства генерирования отчетов на основе информации из центрального репозитория автоматически генерируют системную документацию.

6. Средства создания форм определяют форматы экранных форм и документов.

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

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

29. CASE-технология: назначение, состав и ключевые возможности

CASE (Computer-Aided Software/System Engineering) означает проектирование программного обеспечения или системы на основе компьютерной поддержки. CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей.

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

Главные составляющие CASE-продукта таковы:

* методология (Method Diagrams), которая задает единый графический язык и правила работы с ним;

* графические редакторы (Graphic Editors), которые помогают рисовать диаграммы; возникли с распространением PC и GUI, так называемых «upper case» технологий;

* генератор: по графическому представлению модели можно сгенерировать исходный код для различных платформ (так называемая low case часть CASE-технологии);

* репозиторий.

30. CASE-средства: назначение и выполняемые функции

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

Выполняемые функции:

* оптимизации структуры ИС

* снижение расходов на разработку

* повышение эффективности ИС

* снижение вероятности ошибок при проектировании ИС31.

Репозиторий. Роль репозитория в автоматизации процессов разработки ИС. Репозиторий представляет собой специализированную БД, которая используется для отображения состояния системы в любой момент времени и содержит информацию обо всех объектах проектной ИС:

* имена проектировщиков и их права доступа

* организованные структуры

* компоненты диаграмм и диаграммы в целом

* структуры данных

* взаимосвязи между диаграммами

* программные модули, процедуры и библиотеки модулей

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

32. Подходы к автоматизации процессов разработки ИС

В процессе создания ИС разработчиками используются два альтернативных подхода: структурный и объектно-ориентированный.

33. Структурный подход (информационные, функциональные, структурные модели)

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

* анализа предметной области,

* проектирования,

* создания программных модулей,

* объединения модулей в единую систему тестирования,

* внедрения.

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

34. Объектно-ориентированный подход

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

* абстрагирование;

* инкапсуляция;

* модульность;

* иерархия;

* типизация;

* параллелизм;

* устойчивость.

Основными понятиями объектно-ориентированного подхода являются объект и класс.

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

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

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

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

35. CASE-технологии

CASE-технология в настоящее время попала в разряд наиболее стабильных. Однако, несмотря на все потенциальные возможности CASE средств, существует множество примеров их неудачного внедрения, в результате которых CASE средства становятся «полочным» ПО (shelfware). В связи с этим необходимо отметить следующее:

* CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

* реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

Ключом к успешному внедрению CASE-средств является готовность организации, которая включает следующие аспекты:

* Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;

* Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;

* Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

В случае отсутствия готовности по данным аспектам внедрение CASE средств скорее всего закончится неудачей независимо от степени тщательности следования различным рекомендациям по внедрению.

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

...