1.1 Понятие термина – «CASE-средства»
Первоначально под термином «CASE-технология» (Computer – Aided Software Engineering) понималось буквально – «автоматизированная разработка ПО ИС с помощью компьютерных технологий».
В настоящее время под термином CASE-средства понимаются обширный набор программных средств, поддерживающих процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
CASE-технологии представляют собой совокупность методологий и инструментарий аналитиков, разработчиков и программистов, предназначенный для автоматизации процессов проектирования и сопровождения ИС на всем периоде жизненного цикла .
Методология CASE-средства определяет этапы и шаги реализации проекта, а также правила использования методов, которыми разрабатывается проект. МетодCASE-средства –это процедура или техника генерации описаний компонентов информационной системы (проектирование потоков и структур данных). Нотация CASE-средства – отображение структуры системы, элементов данных с помощью специальных графических символов.
CASE-средства – это специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования информационных систем. CASE-технология, в рамках методологии, включает в себя методы, с помощью которых на основе нотаций строятся диаграммы, поддерживаемые конкретным CASE-средством. CASE-технологии не могут считаться самостоятельными, они только обеспечивают высокую эффективность их применения, определяемую временем разработки проекта.
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл программного обеспечения. Наиболее трудоемкими этапами разработки информационных систем являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
1.2 Типовая структура CASE-средств
CASE-средства служат инструментарием для поддержки и использования методов структурного анализа в проектировании. Эти инструменты поддерживают работу пользователей при создании и редактировании графического проекта в интерактивном режиме. Они способствуют организации проекта в виде иерархии уровней абстракции, выполняют проверки соответствия компонентов. Фактически CASE-средства представляют собой новый тип графически-ориентированных инструментов, восходящих к системе поддержки ЖЦ ПО. Обычно к ним относят любое программное средство, обеспечивающее автоматическую помощь при разработке ПО, его сопровождении или деятельности по управлению проектом, и проявляющее следующие дополнительные характеристики:
мощная графика для описания и документирования систем ПО со специфическим интерфейсом пользователя, развивающая творческие возможности специалистов и не отвлекающая их от процесса проектирования на решение второстепенных вопросов;
интеграция, обеспечивающая легкость передачи данных между средствами и позволяющая управлять всем процессом проектирования и разработки ПО непосредственно через процесс планирования проекта;
использование компьютерного хранилища (репозитария) для шаблонов частей и отдельных элементов проекта, которые могут использоваться различными разработчиками, как основа для автоматического продуцирования ПО и повторного его использования в будущих системах.
Помимо перечисленных основополагающих принципов графической ориентации, интеграции и локализации всей проектной информации в репозитарии в основе концептуального построения CASE-средств лежат следующие положения :
1. Человеческий фактор, определяющий разработку ПО как легкий, удобный и экономичный процесс.
2. Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др.).
3. Автоматизированная или автоматическая кодогенерация, для различных платформ и различного вида кода: преобразования для получения документации; формирования структуры БД, ввода/модификации данных; получения выполняемых машинных кодов из спецификаций ПО; сборки модулей из словарей и моделей данных и повторно используемых программ.
4. Простота использования, позволяющая получать компоненты, поддающиеся управлению, обозримые и доступные для понимания, а также обладающие простой и ясной структурой.
5. Доступность для разных категорий пользователей.
6. Рентабельность.
7. Эффективное решение задач по сопровождению разработанного проекта, обеспечивающая способность адаптации при изменении требований и целей проекта заказчиком.
В состав практически всех современных CASE-средств входят следующие элементы :
репозиторий, позволяет обеспечить сохранность шаблонов проекта и его определенных компонентов, синхронизацию информации от разных разработчиков в процессе групповой разработки, проверка метаданных на полноту и непротиворечивость;
средства разработки приложений, с использованием языков 4GL и генераторов кодов;
средства тестирования;
средства документирования;
графические средства анализа и проектирования, которые дают возможность создавать и редактировать модели информационных систем в виде иерархически связанных диаграмм в реализованной нотации конкретной методологии;
средства реинжиниринга;
средства конфигурационного управления;
средства управления проектом.
1.3 Эволюция развития CASE-технологий
С самого начала CASE-технологии развивались с целью преодоления ограничений «ручного» применения методологии структурного анализа и проектирования 60-70-х годов за счет ее автоматизации и интеграции в поддерживающие средства. Таким образом, CASE-технологии не могут считаться самостоятельными методологиями моделирования, они только делают более эффективными их применение, с точки зрения времени разработки.
Традиционно выделяют шесть периодов, качественно отличающихся применяемой техникой и методами разработки ПО, которые характеризуются использованием в качестве инструментальных средств:
1. Ассемблеров, дампов памяти, анализаторов;
2. Компиляторов, интерпретаторов, трассировщиков;
3. Символьных отладчиков, пакетов программ;
4. Систем анализа и управления исходными текстами;
5. CASE-средств анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (первая генерация CASE-I);
6. CASE-средств генерации исходных текстов и реализации интегрированного окружения поддержки полного жизненного цикла разработки ПО (вторая генерация CASE-II)
CASE-I является первой технологией, адресованной непосредственно системным аналитикам и проектировщикам, и включающей средства для поддержки графических моделей, проектирования спецификаций, экранных редакторов и словарей данных. Она не предназначена для поддержки полного жизненного цикла и концентрирует внимание на функциональных спецификациях и начальных шагах проекта - системном анализе, определении требований, системном проектировании, логическом проектировании БД .
CASE-II отличается значительно более развитыми возможностями, улучшенными характеристиками и исчерпывающим подходом к полному жизненному циклу разрабатываемого ПО. В инструментарии CASE-II, в первую очередь, используются средства поддержки автоматической кодогенерации, а также, обеспечивается полная функциональная поддержка для выполнения графических системных требований и спецификаций проектирования; контроля, анализа и связывания системной информации и информации по управлению проектированием; построение прототипов и моделей системы; тестирования, верификации и анализа сгенерированных программ; генерации документов по проекту; контроля на соответствие стандартам по всем этапам жизненного цикла. CASE-II может включать свыше 100 функциональных компонент, поддерживающих все этапы жизненного цикла, при этом пользователям предоставляется возможность выбора необходимых средств и их интеграции в нужном составе .
1.4 Методологии проектирования, используемые в CASE–средствах
CASE-средства являются результатом естественного эволюционного развития отрасли инструментальных (или технологических) средств. CASE-технологии начали развиваться с целью преодоления ограничений методологии структурного программирования.
Эта методология, несмотря на формализацию в составлении программ, характеризуется все же сложностью понимания, большой трудоемкостью и стоимостью использования, трудностью внесения изменений в проектные спецификации. Заложенные в ней принципы позволили развивать эту методологию и повысить е эффективность за счет автоматизации наиболее рутинних этапов (рис. 1.1).
Основными стандартами методологий, реализованных в CASE-средствах, являются:
SADT (Structured Analysis and Design Technique) - методология структурного анализа и проектирования. Основана на понятиях функционального моделирования. Отражает такие системные характеристики, как управление, обратная связь и исполнитель;
IDEF0 (Integrated Definition Function Modeling) - методология функционального моделирования. Используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, преобразуемые этими функциями. Является подмножеством методологии SADT;
DFD(DataFlow Diagram) - методология моделирования потоков данных.
Рисунок 1.1 – Сравнение традиционной разработки и разработки с использованием CASE-технологий
Следующие стандарты методологий применяются для описания обмена данными между рабочими процессами:
IDEF1 применяется для построения информационной модели, отображающей структуру и содержание информационных потоков, необходимых для поддержки функций системы;
IDEF2 позволяет построить динамическую модель меняющихся во времени поведения функций, информации и ресурсов системы;
IDEF3- методология моделирования потоков работ. Является более детальной по отношению к IDEF0 и DFD. Позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса;
IDEF1X (IDEF1 Extended) - методология описания данных. Применяется для построения баз данных. Относится к типу методологий «Сущность-связь» (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;
IDEF4 - объектно-ориентированная методология. Отражает взаимодействие объектов. Позволяет наглядно отображать структуру объектов и заложенные принципы их взаимодействия. Удобна для создания программных продуктов на объектно-ориентированных языках;
IDEF5- методология онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени;
ARIS - описывает бизнес-процесс в виде потока последовательно выполняемых работ;
UML - (Unified Modeling Language) унифицированный язык моделирования, основанный на объектно-ориентированном подходе. UML позволяют описать статическую структуру системы и ее динамическое поведение в соответствующих нотациях.
В CASE-средствах широко используются методологии структурного и объектно-ориентированного проектирования. Структурное проектирование основано на алгоритмической декомпозиции, а объектно-ориентированное проектирование – на объектно-ориентированной декомпозиции. Алгоритмическая декомпозиция позволяет определить порядок происходящих событий. Объектно-ориентированная декомпозиция позволяет определить иерархию классов объектов, их методы и свойства. CASE-средства, поддерживающие объектно-ориентированное проектирование используют методологию RUP (Rational Unified Process) и нотации языка UML.
1.5 Методология CASE-средств объектно-ориентированного проектирования
В объектно-ориентированном подходе основная категория объектной модели – класс, объединяет в себе на элементарном уровне, как данные, так и операции, которые над ними выполняются (методы). Именно с этой точки зрения изменения, связанные с переходом от структурного к объектно-ориентированному подходу, являются наиболее заметными. Разделение процессов и данных преодолено, однако остается проблема преодоления сложности системы, которая решается путем использования механизма компонентов.
Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Отсюда следует главное достоинство объектно-ориентированного подхода, которое Гради Буч сформулировал следующим образом: объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований.
Буч отмечает также ряд следующих преимуществ объектно-ориентированного подхода .
1. Объектная декомпозиция дает возможность создавать программные системы меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования не только программ, но и проектов, что в конце концов ведет к созданию среды разработки и переходу к сборочному созданию ПО. Системы зачастую получаются более компактными, чем их структурные эквиваленты, что означает не только уменьшение объема программного кода, но и удешевление проекта за счет использования предыдущих разработок.
2. Объектная декомпозиция уменьшает риск создания сложных систем ПО, так как она предполагает эволюционный путь развития системы на базе относительно небольших подсистем. Процесс интеграции системы растягивается на все время разработки, а не превращается в единовременное событие.
3. Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.
4. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.
К недостаткам объектно-ориентированного подхода относятся некоторое снижение производительности функционирования ПО и высокие начальные затраты. Объектная декомпозиция существенно отличается от функциональной, поэтому переход на новую технологию связан как с преодолением психологических трудностей, так и дополнительными финансовыми затратами. Безусловно, объектно-ориентированная модель наиболее адекватно отражает реальный мир, представляющий собой совокупность взаимодействующих (посредством обмена сообщениями) объектов. Но на практике в настоящий момент продолжается формирование стандарта языка UML для объектно-ориентированного моделирования, и количество CASE-средств, поддерживающих объектно-ориентированный подход, невелико по сравнению с аналогичными средствами, поддерживающими структурный подход.
Кроме того, диаграммы, отражающие специфику объектного подхода (диаграммы классов и т.п.), гораздо менее наглядны и плохо понимаемы непрофессионалами. Поэтому одна из главных целей внедрения CASE-технологии, а именно снабжение всех участников проекта (в том числе и заказчика) общим языком «для передачи понимания», обеспечивается на сегодняшний день только структурными методами.
При переходе от структурного подхода к объектному, как при всякой смене технологии, необходимо вкладывать деньги в приобретение новых инструментальных средств. Здесь следует учесть и расходы на обучение (овладение методом, инструментальными средствами и языком программирования). Для некоторых организаций эти обстоятельства могут стать серьезными препятствиями. Объектно-ориентированный подход не дает немедленной отдачи. Эффект от его применения начинает сказываться после разработки двух-трех проектов и накопления повторно используемых компонентов, отражающих типовые проектные решения в данной области. Переход организации на объектно-ориентированную технологию - это смена мировоззрения, а не просто изучение новых CASE-средств и языков программирования .
Очевидно, что в конкретном проекте декомпозировать сложную систему одновременно двумя способами невозможно. Можно начать декомпозицию каким-либо одним способом, а затем, используя полученные результаты, попытаться рассмотреть систему с другой точки зрения. Теперь перейдем к рассмотрению взаимосвязи между структурным и объектно-ориентированным подходами. Основой взаимосвязи является общность ряда категорий и понятий обоих подходов (процесс и вариант использования, сущность и класс и др.). Эта взаимосвязь может проявляться в различных формах. Так, одним из возможных подходов является использование структурного анализа как основы для объектно-ориентированного проектирования. Такой подход целесообразен ввиду широкого распространения CASE-средств, поддерживающих структурный анализ. Структурный анализ продолжается до момента, при котором диаграммы потоков данных начинают отражать не только предметную область, но и систему ПО.
После выполнения структурного анализа и построения диаграмм потоков данных вместе со структурами данных и другими результатами анализа можно различными способами приступить к определению классов и объектов. Так, если взять какую-либо отдельную диаграмму, то кандидатами в объекты могут быть внешние сущности и накопители данных, а кандидатами в классы - потоки данных.
Другой формой проявления взаимосвязи можно считать интеграцию объектной и реляционной технологий. Реляционные СУБД являются на сегодняшний день основным средством реализации крупномасштабных баз данных и хранилищ данных. Причины этого очевидны: реляционная технология используется достаточно долго, освоена огромным количеством пользователей и разработчиков, стала промышленным стандартом, в нее вложены значительные средства и создано множество корпоративных БД в самых различных отраслях, реляционная модель проста и имеет строгое математическое основание; существует большое разнообразие промышленных средств проектирования, реализации и эксплуатации реляционных БД. Вследствие этого реляционные БД в основном используются для хранения и поиска объектов в так называемых объектно-реляционных системах. Объектно-ориентированное проектирование имеет точки соприкосновения с реляционным проектированием. Например, как было отмечено выше, классы в объектной модели могут некоторым образом соответствовать сущностям (в качестве упражнения можно предложить детально проанализировать все сходства и различия диаграмм «сущность-связь» и диаграмм классов). Как правило, такое соответствие имеет место только на ранней стадии разработки системы - стадии формирования требований. В дальнейшем, разумеется, цели объектно-ориентированного проектирования (адекватное моделирование предметной области в терминах взаимодействия объектов) и разработки реляционной БД (нормализация данных) расходятся. Таким образом, единственно возможным средством преодоления данного пробела является определение соответствия между объектно-ориентированной и реляционной технологиями, которое в основном сводится к отображению диаграмм классов и диаграмм «сущность – связь» реляционной модели. Одним из примеров практической реализации взаимосвязи между структурным и объектно-ориентированным подходом является программный интерфейс (мост) между структурным CASE-средством Silverrun и объектно-ориентированным CASE-средством Rational Rose, разработанный российской компанией "Аргуссофт" .Это ПО создает диаграммы классов Rational Rose на основе RDM-модели (Relational Data Model - реляционная модель данных) Silverrun и наоборот. Аналогичные интерфейсы существуют также между CASE-средствами ERwin (с одной стороны), Rational Rose и Paradigm Plus (с другой стороны).
1.6 Методология CASE-средств структурного проектирования
Сущность структурного подхода к разработке информационных систем заключается в ее декомпозиции (разбиении) на автоматизируемые функции. Автоматизируемая система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве основных принципов используются:
принцип декомпозиции - принцип решения сложных проблем путем их разбиения на множество более мелких и независимых задач, легких для понимания и решения;
принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
принцип формализации –- заключается в необходимости строгого методического подхода к решению проблемы;
принцип непротиворечивости - заключается в обоснованности и согласованности использования элементов системы;
принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными.
Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными из них являются следующие :
SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
DFD (Data Flow Diagrams) диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) диаграммы «сущность-связь».
На стадии проектирования информационной системы (ИС) модели усложняются, уточняются и дополняются диаграммами, отражающими структуру и архитектуру программного обеспечения, структурные схемы программ и диаграмм экранных форм. Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
2.2 Разработка концептуальной модели информационной системы.
Концептуальная модель представляет объекты и их взаимосвязи без указывания способов их физического хранения. Таким образом, концептуальная модель является, по существу, моделью предметной области. При проектировании концептуальной модели должна происходить структуризация данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности
обработки. Проектирование концептуальной модели основано на анализе задач, стоящих перед рекламным агентством. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных.
Чтобы построить необходимую нам модель, мы привели все имеющиеся данные к третьей нормальной форме, в результате чего получили следующие сущности:
· Виды блюд.
· Персонал.
· Должности.
· Постоянные клиенты.
· Заказы.
Модель строим на логическом уровне (см. рис. 2). Из рисунка 2 видно, что в модели проставлены связи. Рассмотрим их подробнее:
Таблица «Виды блюд» и таблица «Блюда» - установлена связь «один-ко-многим» при помощи первичного ключа «Код вида»;
Таблица «Должности» и таблица «Персонал» - установлена связь «один-ко-многим» при помощи первичного ключа «Код должности»;
Таблица «Блюда» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код блюда»;
Таблица «Персонал» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код работника»;
Таблица «Постоянные клиенты» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код клиента».
Рис. 2. Концептуальная модель данных
2.3 Разработка логической модели информационной системы
Базы данных и программные средства их создания и ведения (СУБД) имеют многоуровневую архитектуру, представление о которой можно получить из рисунка 1.
Схема 1 - Многоуровневое представление данных БД под
управлением СУБД
Различают концептуальный, внутренний и внешний уровни представления этих баз данных, которым соответствуют модели аналогичного назначения.
Концептуальный уровень соответствует логическому аспекту представления данных предметной области в интегрированном виде. Концептуальная модель состоит из множества экземпляров различных типов данных, структурированных в соответствии с требованиями СУБД к логической структуре базы данных.
Внутренний уровень отображает требуемую организацию данных в среде хранения и соответствует физическому аспекту представления данных. Внутренняя модель состоит из отдельных экземпляров записей, физически хранимых во внешних носителях.
Внешний уровень поддерживает частные представления данных, требуемые конкретным пользователям. Внешняя модель является подмножеством концептуальной модели. Возможно пересечение внешних моделей по данным. Частная логическая структура данных для отдельного приложения (задачи) или пользователя соответствует внешней модели или подсхеме БД. С помощью внешних моделей поддерживается санкционированный доступ к данным БД приложений (ограничен состав и структура данных концептуальной модели БД, доступных в приложении, а так же заданы допустимые режимы обработки этих данных: ввод, редактирование, удаление, поиск).
Проектирование базы данных состоит в построении комплекса взаимосвязанных данных. На рисунке 2 условно отображены этапы процесса проектирования базы данных.
Схема 2 - Этапы процесса проектирования базы данных
Важнейшим этапом проектирования базы данных является разработка информационно-логической (инфологической) модели предметной области, не ориентированной СУБД. В инфологической модели средствами структур данных в интегрированном виде отражают состав и структуру данных, а также информационные потребности.
Информационно-логическая (инфологическая) модель предметной области отражает предметную область в виде совокупности информационных объектов и их структурных связей.
При связи один ко многим (1:М) одному экземпляру информации А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с одним экземпляром объекта А.
Примером связи 1:М служит связь между информационными объектами Фамилия – Оклад:
Фамилия Оклад
В базе данных информация хранится в виде двумерных таблиц. Можно так же импортировать и связывать таблицы из других СУБД или систем управления электронными таблицами. Одновременно могут быть открыты 1024 таблицы.
При определении необходимых таблиц базы данных необходимо обеспечить первые три нормальные формы, т.е. провести нормализацию.
Одни и те же данные могут группироваться в таблицы (отношения) различными способами, т.е. возможна организация различных наборов отношений взаимосвязанных информационных объектов. Группировка атрибутов в отношениях должна быть рациональной, т.е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления.
Определённый набор отношений обладает лучшими свойствами при включении, модификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений.
Нормализация отношений – формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Е.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.
Первая нормальная форма. Отношение называется нормализованным или приведённым к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.
Вторая нормальная форма. Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость.
Описательные реквизиты информационного объекта логически связаны с общим для них ключом, эта связь носит характер функциональной зависимости реквизитов.
Функциональная зависимость реквизитов – зависимость, при которой в экземпляре информационного объекта определённому значению ключевого реквизита соответствует только одно значение описательного реквизита.
Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты. В качестве примера рассмотрим графическое изображение функциональных зависимостей реквизитов работников, приведенное на рисунке 5, на котором ключевой реквизит указан звёздочкой.
Рисунок 1 - Графическое изображение функциональной зависимости реквизитов
В случае составного ключа вводится понятие функционально полной зависимости.
Функционально полная зависимость не ключевых атрибутов заключается в том, что каждый не ключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.
Отношение будет находиться во второй нормальной форме, если оно находится в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависит от составного ключа.
Третья нормальная форма. Понятие третьей нормальной формы основывается на понятии не транзитивной зависимости.
Транзитивная зависимость наблюдается в том случае, если один из двух описательных реквизитов зависит от ключа, а другой описательный реквизит зависит от первого описательного реквизита.
Отношение будет находиться в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Для устранения транзитивной зависимости описательных реквизитов необходимо провести “расщепление” исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов.
Создаваемая база данных должна выполнять функции в интересах автоматизации выдачи данных об организации. Она должна иметь простой и наглядный пользовательский интерфейс, иметь минимальные системные требования.
Целью работы является создание базы данных, обеспечивающей:
быстрый ввод новых данных;
хранения и поиск уже введённых данных;
печать необходимого количества персональных отчётов.
Данными являются:
Фамилия, имя, отчество;
Дата рождения;
Занимаемая должность;
Должностной оклад;
Количество фактических дней отработанных за месяц.
Рассмотрев определенные выше задачи можно спроектировать основные таблицы базы данных.
Для этого будем пользоваться средствами Database Desktop
В этой среде создадим все необходимые таблицы для разрабатываемой базы данных. Атрибутами в этой таблице будет:
Фамилия, Имя, Отчество, Дата принятия, Адрес, Телефон, Смены, Не выходы на работу, Ставка, зарплата.
Обзор некоторых CASE-систем.
Список производителей CASE - инструментов и ряд полезных ссылок можно найти по адресу http://sunny.aha.ru/~belikov/index.htm, вопросам использования CASE посвящена русскоязычная конференция news://fido7.su.dbms.case/, в Internet также доступна книга Вендрова А.М. CASE-технологии. Современные методы и средства проектирования информационных систем..
Power Designer компании Sybase.
В состав Power Designer входят следующие модули:
· Process Analyst - средство для функционального моделирования, поддерживает нотацию Йордона - ДеМарко, Гейна - Сарсона и несколько других. Имеется возможность описать элементы данных (имена, типы, форматы), связанные с потоками данных и хранилищами данных. Эт элементы передаются на следующий этап проектирования, причем хранилища данных могут быть автоматически преобразованыв сущности.
· Data Analyst - инструмент для построения модели "сущность-связь" и автоматической генерации на ее основе реляционной структуры. Исходные данные для модели "сущность-связь" могут быть получены из DFD-моделей, созданных в модуле Process Analyst. В ER-диаграммах допускаются только бинарные связи, задание атрибутов у связей не поддерживается. Поддерживаются диалекты языка SQL примерно для 30 реляционных СУБД, при этом могут быть сгенерированы таблицы, представления, индексы, триггеры и т.д. В результате порождается SQL-сценарий (последовательность команд CREATE), выполнение которого создает спроектированную схему базы данных. Имеется также возможность установить соединение с СУБД через интерфейс ODBC. Другие возможности: автоматическая проверка правильности модели, расчет размера базы данных, реинжиниринг (построение модельных диаграмм для уже существующих баз данных) и т.д.
· Application Modeler - инструмент для автоматической генерации прототипов программ обработки данных на основе реляционных моделей, построенных в Data Analyst. Может быть получен код для Visual Basic, Delphi, а также для таких систем разработки в архитектуре "клиент-сервер" как PowerBuilder, Uniface, Progress и др. Генерация кода осуществляется на основе шаблонов, соответственно управлять генерацией можно за счет изменения соответствующего шаблона.
Ознакомительную версию Power Designer, в которой заблокированы функции сохранения построенных моделей, можно получить с российского web-сервера комании Sybase.
Silverrun компании Silverrun Technologies Ltd.
CASE-система Silverrun состоит из следующих инструментов:
· BPM - построение DFD-диаграмм. Поддерживает нотации Йордона-ДеМарко, Гейна - Сарсона, Уорда-Меллора и многие другие. Данный инструмент позволяет автоматически проверить целостность построенной модели, причем список критериев проверки определяется пользователем (например: отсутствие имен у элементов модели, потоки данных типа "хранилище - хранилище" или "внешняя сущность - внешняя сущность" и т.д.)
· ERX - построение диаграмм "сущность-связь". Поддерживаются не только бинарные связи, но и связи более высоких порядков, имеется возможность определения атрибутов у связей. Построенные ER-модели с помощью внешней утилиты могут быть сконвертированы в реляционный структуры (в той версии, с которой я работал, при этом, к сожалению, терялись атрибуты связей).
· RDM - инструмент реляционного моделирования, позволяет генерировать SQL-скрипты для создания таблиц и индексов примерно для 25 целевых СУБД.
Следует отметить, что компания Silverrun Technologies Ltd является не только разработчиком CASE - инструментария, но также создала собственную методологию создания информационных систем, получившую название Datarun. Эта методология включает описание всех этапов жизненного цикла информационной системы, перечень и последовательность работ, требования к содержанию и оформлению документов и многое другое.
Ознакомительную версию Silverrun, можно скачать с сервера комании Argussoft. В этой версии имеются ограничения на количество элементов в создаваемых моделях.
BPWin и ERWin компании LogicWorks.
LogickWorks выпускает два взаимнодополняющих инструмента проектирования информационных систем:
· BPWin - функциональное моделирование на основе методологии IDEF0. Допускается также использовние нотации IDEF3 и DFD в нотации Йордона - ДеМарко. Имеется возможность экспорта построенных моделей в системы функционально-стоимостного анализа (ABC - Activity Based Costing) и информационного моделирования ERWin.
· ERWin - средство информационного моделирования, используется нотация IDEF1X. Поддерживаются свыше 20 целевых СУБД, имеется возможность генерации прототипов прикладных программ для Visual Basic, Delphi и т.д.
Использование SilverRun
Методология
Планирование и разработка комплексных информационных систем невозможны без тщательно обдуманного методологического подхода. Какие этапы необходимо пройти, какие методы и модели использовать, как организовать контроль за продвижением проекта и качеством выполнения работ - эти вопросы решаются методологиями программной инженерии. Методологий существует много, и главное в них - единая дисциплина работы на всех этапах жизненного цикла системы. Если учитываются все критические задачи и контролируется их решение, качество создаваемых систем значительно возрастает. При этом, в общем случае, не важно, какие конкретно методы были выбраны для решения этих задач.
Для различных классов систем используются свои методы разработки. Они определяются как типом создаваемой системы, так и средствами реализации. Вероятно, самыми распространенными по объемам разработок являются информационные системы бизнес-класса. Практически в каждой организации имеются специалисты, разрабатывающие или сопровождающие информационные системы. Спецификация этих систем в большинстве случаев состоит из двух основных компонентов: функционального и информационного. По способу сочетания этих компонентов подходы к представлению информационных систем можно разбить на два основных типа - структурный и объектно-ориентированный. Разумеется, объектно-ориентированные методы также являются структурными в прямом понимании этого слова. Но исторически в программной инженерии этот термин закрепился за рядом дисциплин: структурное программирование, структурный дизайн, структурный анализ. В структурных технологиях функциональная и информационная модели строятся отдельно, чаще всего в виде диаграмм потоков данных и диаграмм "сущность-связь". Объектно-ориентированные технологии рассматривают информацию неотъемлемо от процедур ее обработки. Модели объектно-ориентированных технологий описывают структуру, поведение и реализацию систем в терминах классов объектов.
Объектно-ориентированные технологии доминируют в области создания операционных систем, средств разработки и исполнения приложений, систем реального времени. Концепция объекта помогает бороться с быстро растущей сложностью систем. Кроме того, взаимодействующие электронные устройства, как и элементы программ, естественно представляются объектами.
В области создания бизнес-систем лидируют структурные технологии, так как они максимально приспособлены для взаимодействия с заказчиками и пользователями, не являющимися специалистами в области информационных технологий. А анализ опыта разработок информационных систем показал, что активное привлечение пользователей на этапах выявления требований и постановки задачи является критическим фактором успеха крупных проектов. При разработке систем бизнес-класса основные усилия затрачиваются именно на понимание и спецификацию требований пользователя, а для реализации используются покупные средства разработки приложений (чаще всего языки четвертого поколения) и системы управления базами данных (чаще всего реляционные).
В терминах вышесказанного, место системы SILVERRUN в технологиях программной инженерии можно определить следующим образом: это CASE-система верхнего уровня, предназначенная для инструментальной поддержки структурных методологий создания информационных систем бизнес-класса. Таким образом, эта система может быть использована специалистами, занимающимися анализом и моделированием деятельности предприятий, разработчиками информационных систем, администраторами баз данных.
Методология RAD
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
· небольшую команду программистов (от 2 до 10 человек);
· короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
· повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
· фаза анализа и планирования требований;
· фаза проектирования;
· фаза построения;
· фаза внедрения.
На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС.
На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.
После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:
· общая информационная модель системы;
· функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
· точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
· построенные прототипы экранов, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация.
На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:
· определяется необходимость распределения данных;
· производится анализ использования данных;
· производится физическое проектирование базы данных;
· определяются требования к аппаратным ресурсам;
· определяются способы увеличения производительности;
· завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.
Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается.
Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом:
В качестве итога перечислим основные принципы методологии RAD:
· разработка приложений итерациями;
· необязательность полного завершения работ на каждом из этапов жизненного цикла;
· обязательное вовлечение пользователей в процесс разработки ИС;
· необходимое применение CASE-средств, обеспечивающих целостность проекта;
· применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
· необходимое использование генераторов кода;
· использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;
· тестирование и развитие проекта, осуществляемые одновременно с разработкой;
· ведение разработки немногочисленной хорошо управляемой командой профессионалов;
· грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
Структурный подход
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
· принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
· принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:
· принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
· принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
· принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
· принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
· SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
· DFD (Data Flow Diagrams) диаграммы потоков данных;
· ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".
На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.
Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
Лекция 8. Case средства разработки информационных систем
Характеристики современных операционных систем
Год за годом происходит эволюция структуры и возможностей операционных систем. В последнее время в состав новых операционных систем и новых версий уже существующих операционных систем вошли некоторые структурные элементы, которые внесли большие изменения в природу этих систем. Современные операционные системы отвечают требованиям постоянно развивающегося аппаратного и программного обеспечения. Они способны управлять работой многопроцессорных систем, работающих быстрее обычных машин, высокоскоростных сетевых приспособлений и разнообразных запоминающих устройств, число которых постоянно увеличивается. Из приложений, оказавших влияние на устройство операционных систем, следует отметить мультимедийные приложения, средства доступа к Internet, а также модель клиент/сервер.
Неуклонный рост требований к операционным системам приводит не только к улучшению их архитектуры, но и к возникновению новых способов их организации. В экспериментальных и коммерческих операционных системах были опробованы самые разнообразные подходы и структурные элементы, большинство из которых можно объединить в следующие категории.
· Архитектура микроядра.
· Многопоточность.
· Симметричная многопроцессорность.
· Распределенные операционные системы.
· Объектно-ориентированный дизайн.
Отличительной особенностью большинства операционных систем на сегодняшний день является большое монолитное ядро. Ядро операционной системы обеспечивает большинство ее возможностей, включая планирование, работу с файловой системой, сетевые функции, работу драйверов различных устройств, управление памятью и многие другие. Обычно монолитное ядро реализуется как единый процесс, все элементы которого используют одно и то же адресное пространство. В архитектуре микроядра ядру отводится лишь несколько самых важных функций, в число которых входят работа с адресными пространствами, обеспечение взаимодействия между процессами (interprocess communication - IPC) и основное планирование. Работу других сервисов операционной системы обеспечивают процессы, которые иногда называют серверами. Эти процессы запускаются в пользовательском режиме и микроядро работает с ними так же, как и с другими приложениями. Такой подход позволяет разделить задачу разработки операционной системы на разработку ядра и разработку сервера. Серверы можно настраивать для требований конкретных приложений или среды. Выделение в структуре системы микроядра упрощает реализацию системы, обеспечивает ее гибкость, а также хорошо вписывается в распределенную среду. Фактически микроядро взаимодействует с локальным и удаленным сервером по одной и той же схеме, что упрощает построение распределенных систем.
Многопоточность (multithreading) - это технология, при которой процесс, выполняющий приложение, разделяется на несколько одновременно выполняемых потоков. Ниже приведены основные различия между потоком и процессом.
· Поток. Диспетчеризуемая единица работы, включающая контекст процессора (куда входит содержимое программного счетчика и указателя вершины стека), а также свою собственную область стека (для организации вызова подпрограмм и хранения локальных данных). Команды потока выполняют ся последовательно; поток может быть прерван при переключении процессора на обработку другого потока 4 .Процесс. Набор из одного или нескольких потоков, а также связанных с этими потоками системных ресурсов (таких, как область памяти, в которую входят код и данные, открытые файлы, различные устройства). Эта концепция очень близка концепции выполняющейся программы. Разбивая приложение на несколько потоков, программист получает все преимущества модульности приложения и возможность управления связанными с приложением временными событиями.
Многопоточность оказывается весьма полезной для приложений, выполняющих несколько независимых заданий, которые не требуют последовательного исполнения. В качестве примера такого приложения можно привести сервер базы данных, который одновременно принимает и обрабатывает несколько запросов клиентов. Если в пределах одного и того же процесса обрабатываются несколько потоков, то при переключении между различными потоками непроизводительный расход ресурсов процессора меньше, чем при переключении между разными процессами. Кроме того, потоки полезны при описанном в последующих главах структурировании процессов, которые являются частью ядра операционной системы.
До недавнего времени все персональные компьютеры, рассчитанные на одного пользователя, и рабочие станции содержали один виртуальный микропроцессор общего назначения. В результате постоянного повышения требований к производительности и понижения стоимости микропроцессоров производители перешли к выпуску компьютеров с несколькими процессорами. Для повышения эффективности и надежности используется технология симметричной многопроцессорности (symmetric multiprocessing - SMP). Этот термин относится к архитектуре аппаратного обеспечения компьютера, а также к образу действий операционной системы, соответствующему этой архитектурной особенности. Симметричную многопроцессорность можно определить как автономную компьютерную систему со следующими характеристиками.
1. В системе имеется несколько процессоров.
2. Эти процессоры, соединенные между собой коммуникационной шиной или какой-нибудь другой схемой, совместно используют одну и ту же основную память и одни и те же устройства ввода-вывода.
3. Все процессоры могут выполнять одни и те же функции (отсюда название симметричная обработка).
Операционная система, работающая в системе с симметричной многопроцессорностью, распределяет процессы или потоки между всеми процессорами. У многопроцессорных систем есть несколько потенциальных преимуществ по сравнению с однопроцессорными, в число которых входят следующие.
· Производительность . Если задание, которое должен выполнить компьютер, можно организовать так, что какие-то части этого задания будут выполняться параллельно, это приведет к повышению производительности по сравнению с однопроцессорной системой с процессором того же типа. Сформулированное выше положение проиллюстрировано на рис. 2.12. В много задачном режиме в один и тот же момент времени может выполняться только один процесс, тогда как остальные процессы вынуждены ожидать своей очереди. В многопроцессорной системе могут выполняться одновременно несколько процессов, причем каждый из них будет работать на от дельном процессоре.
· Надежность. При симметричной мультипроцессорной обработке отказ одного из процессоров не приведет к остановке машины, потому что все процессоры могут выполнять одни и те же функции. После такого сбоя система продолжит свою работу, хотя производительность ее несколько снизится.
· Наращивание . Добавляя в систему дополнительные процессоры, пользователь может повысить ее производительность.
· Масштабируемость. Производители могут предлагать свои продукты в различных, различающихся ценой и производительностью, конфигурациях, предназначенных для работы с разным количеством процессоров.
Важно отметить, что перечисленные выше преимущества являются скорее потенциальными, чем гарантированными. Чтобы надлежащим образом реализовать потенциал, заключенный в многопроцессорных вычислительных системах, операционная система должна предоставлять адекватный набор инструментов и возможностей
Рис. 2.12. Многозадачность и многопроцессорность
Часто можно встретить совместное обсуждение многопоточности и многопроцессорности, однако эти два понятия являются независимыми. Многопоточность - полезная концепция для структурирования процессов приложений и ядра даже на машине с одним процессором. С другой стороны, многопроцессорная система может обладать преимуществами по сравнению с однопроцессорной, даже если процессы не разделены на несколько потоков, потому что в такой системе можно запустить несколько процессов одновременно. Однако обе эти возможности хорошо согласуются между собой, а их совместное использование может дать заметный эффект.
Заманчивой особенностью многопроцессорных систем является то, что наличие нескольких процессоров прозрачно для пользователя -за распределение потоков между процессорами и за синхронизацию разных процессов отвечает операционная система. В этой книге рассматриваются механизмы планирования и синхронизации, которые используются, чтобы все процессы и процессоры были видны пользователю в виде единой системы. Другая задача более высокого уровня - представление в виде единой системы кластера из нескольких отдельных компьютеров. В этом случае мы имеем дело с набором компьютеров, каждый из которых обладает своей собственной основной и вторичной памятью и своими модулями ввода-вывода. Распределенная операционная система создает видимость единого пространства основной и вторичной памяти, а также единой файловой системы. Хотя популярность кластеров неуклонно возрастает и на рынке появляется все больше кластерных продуктов, современные распределенные операционные системы все еще отстают в развитии от одно- и многопроцессорных систем. С подобными системами вы познакомитесь в шестой части книги.
Одним из последних новшеств в устройстве операционных систем стало использование объектно-ориентированных технологий. Объектно-ориентированный дизайн помогает навести порядок в процессе добавления к основному небольшому ядру дополнительных модулей. На уровне операционной системы объектно-ориентированная структура позволяет программистам настраивать операционную систему, не нарушая ее целостности. Кроме того, этот подход облегчает разработку распределенных инструментов и полноценных распределенных операционных систем.
Подходы к проектированию ИС.
Можно выделить два основных подхода к проектированию информационных систем:
· структурный
· процессный .
Структурный подход основан на использовании организационной структуры компании, когда проектирование системы идет по структурным подразделениям. Технологии деятельности в этом случае описываются через технологии работы структурных подразделений и их взаимодействия.
Если компания представляет собой сложную структуру типа холдинга, или предприятие-сеть, то необходимо также иметь модель взаимодействия всех входящих в него элементов, в которой будут отражены не только технологические, но также финансовые и юридические моменты.
Главным недостатком структурного подхода является привязка к организационной структуре, которая очень быстро меняется, поэтому в Системный проект информационной системы приходится часто вносить изменения. А изменение готовой ИС, как правило, достаточно трудоемкий, длительный и утомительный процесс.
Процессный подход ориентирован не на организационную структуру, а на бизнес-процессы, т.е. например фирма занимается поставкой оборудования, поставкой комплектующих и запасных частей, обслуживанием оборудования и т.д. Это и будут ее бизнес-процессы, которые должны быть проанализированы на 1-ом этапе проектирования ИС.
Процессный подход является более перспективным, т.к. бизнес-процессы, в отличие от организационной структуры, меняются реже. Причем основных бизнес-процессов на предприятии немного, обычно не более десяти.
В условиях современности сложность создания информационных систем очень высока. Поэтому при проектировании ИС в настоящее время стало широко использоваться CASE-технология.
CASE-технология – это программный комплекс, автоматизирующий весь технологический процесс анализа, проектирования, разработки и сопровождения сложных программных средств.
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают высокое качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют графические средства моделирования предметной области, которые позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
Интегрированные CASE-средства обладают следующими характерными особенностями :
· обеспечение управления процессом разработки ИС;
· использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированные CASE-средства содержат следующие компоненты:
· графические средства анализа и проектирования, используемые для описания и документирования ИС;
· средства разработки приложений, включая языки программирования и генераторы кодов;
· репозиторий, который обеспечивает хранение версий разрабатываемого проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
· средства управления процессом разработки ИС;
· средства документирования;
· средства тестирования;
· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.
Все современные CASE-средства делятся на две группы. Первую группу организуют средства встроенные в систему реализации, в которых все решения по проектированию и реализации привязаны к выбранной системе управления базами данных. Вторую группу организуют средства независимые от системы реализации, в которых все решения по проектированию ориентированы на унификацию начальных этапов жизненного цикла и средств их документирования. Данные средства обеспечивают большую гибкость в выборе средств реализации.
Основное достоинство CASE-технологии – поддержка коллективной работы над проектом за счет возможности работы в локальной сети, экспорта и импорта отдельных фрагментов проекта между разработчиками, организованного управления проектом.
В качестве этапов создания программных продуктов для информационных систем можно выделить следующие:
1. Определяется среда функционирования. На этом этапе определяются набор процессов жизненного цикла ИС, определяется область примененияИС, определяется размер поддерживаемых приложений, т.е. задается ограничения на такие величины, как количество строк программного кода, размер базы данных, количество элементов данных, количество объектов управления и т.д.
2. Производится построение диаграмм и графический анализ. На этом этапе строятся диаграммы, устанавливающие связь с источниками информации и потребителями, определяющие процессы преобразования данных и места их хранения.
3. Определяются спецификации и требования, предъявляемые к системе (вид интерфейса, тип данных, структура системы, качества, производительности, технические средства, общие затраты и т.д.).
4. Выполняется моделирование данных, т.е. вводится информация, описывающая элементы данных системы и их отношения.
5. Выполняетсямоделирование процессов, т.е. вводится информация, описывающая процессы системы и их отношения.
6. Выполняется проектирование архитектуры будущего ПО.
7. Выполняется имитационное моделирование, т.е. моделирование различных аспектов функционирования системы на основе спецификаций требований и/или проектных спецификаций.
8. Прототипирование, т.е. создается предварительный вариант всей системы или ее отдельных компонент.
9. Трассировка, выполняется анализ функционирования системы от спецификации требований до конечных результатов.
10. Выполняется генерация программного кода, его компиляция и отладка.
11. Тестирование полученных программных средств. Анализ и оценка полученных результатов.
