Проектирование информационных систем

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

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

Реферат

Проектирование информационных систем



Введение

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

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

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

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

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

функционирование в неоднородной среде на нескольких аппаратных платформах;

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

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

Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели (см. Приложение 1. Этапы проектирование ИC).

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

неадекватная спецификация требований;

неспособность обнаруживать ошибки в проектных решениях;

низкое качество документации, снижающее эксплуатационные качества;

затяжной цикл и неудовлетворительные результаты тестирования.

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

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



Средства и инструменты проектирования

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

Выделяют две основные концепции компьютерного программного обеспечения системы CASE:

простые и «прозрачные» методы упрощения разработки программного обеспечения и/или его технического обслуживания;

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

Типичными CASE инструментами являются:

инструменты управления конфигурацией;

инструменты моделирования данных;

инструменты анализа и проектирования;

инструменты преобразования моделей;

инструменты редактирования программного кода;

инструменты рефакторингаРефакторинг (англ. refactoring) -- процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. кода;

генераторы кода;

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

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

Примеры CASE программ

VisualParadigmforUML - средаUML-моделирования.

Umbrello -- среда UML-моделирования. Это приложение является свободным программным обеспечением, предназначенным для построения UML диаграмм на платформе Unix

Комплект программ Rational Software компании IBM

Power Designer компании Sybase

Oracle Designer компании Oracle

ERwin компании CA Technologies

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

широкое разнообразие качества и возможностей CASE-средств;

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

широкое разнообразие в практике внедрения различных организаций;

отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

широкий диапазон предметных областей проектов;

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

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

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

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

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

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

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

Визуальное моделированиев проектировании ИС

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

компонентную технологию разработки моделей ИС,

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

использование образцов (patterns) при проектировании ИС,

визуальное представление различных аспектов проекта (визуальное моделирование, CASE - средства)

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

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

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

нотацию - визуальное предоставление элементов моделирования;

принципы использования - правила применения элементов в рамках построения тех или иных типов моделей ИС.

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

Технологию RAD целесообразно применять, когда четко определены некоторые приоритетные направления разработки проекта.

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

Нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения.

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

Интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD-технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта.

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

Низкая вычислительная сложность ПО.

RAD-технология не является универсальной, то есть ее применение целесообразно не всегда. Например, в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется и более эффективной может быть иерархическая разработка (каскадный метод). То же касается проектов, ПО, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объем пользовательского интерфейса невелик.



Использование UML для проектирования информационных систем

UML (Unified Modeling Language - унифицированный язык моделирования) - язык графического описания моделей в области разработки программного обеспечения.

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

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

По запросу Object Management Group (OMG) - организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных объектно ориентированых методов - Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.

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

Что обеспечивает UML.

иерархическое описание сложной системы путем выделения пакетов;

формализацию функциональных требований к системе с помощью аппарата вариантов использования;

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

выделение классов данных и построение концептуальной модели данных в виде диаграмм классов;

выделение классов, описывающих пользовательский интерфейс, и создание схемы навигации экранов;

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

описание поведения объектов в виде диаграмм деятельностей и состояний;

описание программных компонент и их взаимодействия через интерфейсы;

описание физической архитектуры системы.

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

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

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

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

повышение качества программного продукта,

сокращение стоимости проекта,

поставка системы в запланированные сроки. Михаил Кумсков. Унифицированный язык моделирования (UML) и его поддержка в Rational Rose 98i - CASE-средстве визуального моделирования

Интермодальная информационная логистическая система

Общие сведения о интермодальныхперевозках

Транспортные фирмы разрабатывают системы перевозок, которые позволят добиться максимальной выгоды. Одной из разновидностей таких грузоперевозок является интермодальная перевозка пассажиров и грузов, основанная на взаимодействии различных видов транспорта, нередко с использованием унифицированных тарифов В августе 2002 года в Москве стала действовать скоростная интермодальная транспортная система: Павелецкий вокзал -- аэропорт «Домодедово». Эту линию обслуживают новейшие скоростные комфортные электропоезда. Расстояние от вокзала до аэропорта (50 км) «поезд-вихрь», мчащийся без остановок, преодолевает за 40 минут. Экспресс прибывает точно по расписанию под изящный миниатюрный дебаркадер, который вырос недавно у входа в аэропорт. Причем пассажирам с билетами на самолет, прошедшим регистрацию в «Красном зале» Павелецкого вокзала, остается только дождаться объявления «на посадку»! Такие поезда ходят по маршруту вокзал -- аэропорт с интервалом 1 час и перевозят ежедневно (в одну сторону) до 5 тысяч пассажиров. С каждым месяцем эта интермодальная система совершенствуется, становится все более популярной.. Для грузоперевозок характерен также, подсбор товаров на различных этапах транспортирования. Данная система использует для выполнения своей задачи различные транспортные средства. (Пример taobao - доставка товаров из Китая).

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

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

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

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

Функции информационной интермодальная логистической системы.

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

Пользователи: перевозчики,экспедиторы,производственные и торговые фирмы. компьютерный программный интермодальный логистический

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

На основе существующих схем возможно создание визуальной модели логистической компании с использованием UML.

Информационная интермодальная логистическая система должна решать ряд проблем:

объединить в себе данные о различных транспортных узлах и агентах;

определять ключевые транспортные узлы (в том числе использовать смешанный транспорт: автоперевозки, порты, ж/д перевозки) для доставки конкретного груза;

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

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

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

Через интерфейс ИС пользователь должен иметь возможность

1.регистрации,

2. авторизации,

3. заключения договора и отплаты услуги оператора логистической системы on-line.

4. cоздания поисковых запросов,

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

6. мониторинга следования груза.

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

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

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

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

Система Gonrand. Одной из задач информационной системы Gon-rand является сбор информации о наличии груза. Перевозчик дает заявку о свободных провозных возможностях и направлении перевозки. Информация заносится в базу данных. Информация о грузах поступает в систему непрерывно. Система позволяет группировать грузы по отправителям, получателям, количеству мест и выдает информацию об отправлении, наименовании грузополучателя, номере автомобиля, заказчике, коде департамента и сумме отправлений по департаментам.

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

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

Система BRS функционирует аналогично системе СТС. Грузоотправитель контактирует не с перевозчиком, а с информационной системой. Фирма гарантирует оплату перевозчикам выполненной перевозки, если заказчик не произвел своевременно оплату, что повышает привлекательность обслуживания, расширяя тем самым охват рынка потребителей.

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

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

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

Система GPS - автоматизированная глобальная спутниковая система, предназначенная для определения широты и долготы местонахождения транспортного средства (судна, самолета, грузового автомобиля и т.п.). Система связана с искусственными спутниками Земли. Каждый спутник непрерывно передает в эфир сигналы времени и координаты своего местонахождения. Транспортное средство должно быть оснащено специальным приемным устройством, которое принимает сигналы с трех спутников одновременно, обрабатывает их и выводит координаты точки местонахождения на дисплей (погрешность результатов составляет не более 3-15 м).



Литература и источники

Башмаков А.И., Башмаков И.А. Интеллектуальные информационные технологии: Учеб. пособие.-М.: Изд-во МГТУ им. Н.Э. Баумана, 2005.-304 с.:ил. - (Информатика в техническом университете).

Головина Е.Ю. Технологии создания корпоративных информационных систем с использованием интеллектуальных методов (Монография. Серия «Технология, оборудования и автоматизация машиностроительных производств»). - М.:Янус-К, 2002. - 107 с., ил. ISBN 5-8037-0085-1

А.М. Вендров. CASE-технологии. Современные методы и средства проектирования информационных систем.

Куликов А.С.Информационные технологии мультимодальных и интермодальных перевозок

Чеботарев А.А., Чеботарев А.Д. "Логистика и маркетинг. Маркетологистика"



Приложение 1

Этапы прoектирования ИС.

№	Наименование этапа	Основные характеристики
1	Разработка и анализ бизнес - модели	Определяются основные задачи АИС, проводится декомпозиция задач по модулям и определяются функции с помощью которых решаются эти задачи. Описание функций осуществляется на языке производственных (описание процессов предметной области), функциональных (описание форм обрабатываемых документов) и технических требований (аппаратное, программное, лингвистическое обеспечение АИС). Метод решения: Функциональное моделирование. Результат: 1.Концептуальная модель АИС, состоящая из описания предметной области, ресурсов и потоков данных, перечень требований и ограничений к технической реализации АИС. 2.Аппаратно-технический состав создаваемой АИС.
2	Формализация бизнес - модели, разработка логической модели бизнес -процессов.	Разработанная концептуальная модель формализуется, т.е. воплощается в виде логической модели АИС. Метод решения: Разработка диаграммы "сущность-связь" (ER (Entity-Reationship) - CASE- диаграммы). Результат: Разработанное информационное обеспечение АИС: схемы и структуры данных для всех уровней модульности АИС, документация по логической структуре АИС, сгенерированные скрипты для создания объектов БД.
3	Выбор лингвистического обеспечения, разработка программного обеспечения АИС.	Разработка АИС: выбирается лингвистическое обеспечение (среда разработки - инструментарий), проводится разработка программного и методического обеспечения. Разработанная на втором этапе логическая схема воплощается в реальные объекты, при этом логические схемы реализуются в виде объектов базы данных, а функциональные схемы - в пользовательские формы и приложения. Метод решения: Разработка программного кода с использованием выбранного инструментария. Результат: Работоспособная АИС.
4	Тестирование и отладка АИС	На данном этапе осуществляется корректировка информационного, аппаратного, программного обеспечения, проводится разработка методического обеспечения (документации разработчика, пользователя) и т.п. Результат: Оптимальный состав и эффективное функционирование АИС. Комплект документации: разработчика, администратора, пользователя.
5	Эксплуатация и контроль версий	Особенность АИС созданных по архитектуре клиент сервер является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то в как показала практика, БД АИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20-30%. Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС

Источник: http://citforum.ru/database/oraclepr/oraclepr_02.shtml



Приложение 2

Виды диаграмм UML.

Use case diagram (диаграммы прецедентов)	Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.Каждая такая диаграмма или, как ее обычно называют, каждый Usecase - это описание сценария поведения, которому следуют действующие лица (Actors).Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты как системы, так и предметной области и задачи, ими выпол няемые.
Deployment diagram (диаграммы топологии)	Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм.Для каждой модели создается только одна такая диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения. Обычно этот тип диаграмм используется в самом начале проектирования системы для анализа аппаратных средств, на которых она будет экс плуатироваться.
StateMaсhinediagram (диаграммы состояний)	Каждый объект системы, обладающий определенным поведением, может находится в определенных состояниях, переходить из состояния в состояние, совершая определенные действия в процессе реализации сценария поведения объекта. Поведение большинства объектов реальных систем можно представить с точки зрения теории конечных автоматов, то есть поведение объекта отражается в его состояниях, и данный тип диаграмм позволяет отразить это графически. Для этого используется два вида диаграмм: Statechartdiagram (диаграмма состояний) и Activity diagram (диаграмма активности)
Statechartdiagram (диаграмма состояний)	Диаграмма состояний (Statechart) предназначена для отображения состояний объектов системы, имеющих сложную модель поведения. Это одна из двух диаграмм StateMachine, доступ к которой осуществляется из одного пункта меню.
Activity diagram (диаграммы активности)	Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activitydiagram в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов. Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.
Interactiondiagram (диаграммы взаимодействия)	Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Sequence diagram (диаграммы последовательностей действий)	Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов. Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами. Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaborationdiagram.
Collaboration diagram (диаграммы сотрудничества)	Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений. По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, RationalRose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.
Class diagram (диаграммы классов)	Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. RationalRose позволяет создавать классы при помощи данного типа диаграмм в различных нотациях. В нотации, предложенной Г. Бучем, которая так и называется Booch, классы изображаются в виде чего-то нечеткого, похожего на облако. Таким образом Г.Буч пытается показать, что класс - это лишь шаблон, по которому в дальнейшем будет создан конкретный объект. Нотация OMT, более строга. И конечно же, RationalRose позволяет создавать диаграмму классов в унифицированной нотации
Component diagram (диаграммы компонентов)	Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей. При проектировании больших систем может оказаться, что система должна быть разложена на несколько сотен или даже тысяч компонентов, и этот тип диаграмм позволяет не потеряться в обилии модулей и их связей.

Источник: Сергей Трофимов.UML диаграммы в Rational Rose.



Приложение 3

Характеристики видов транспорта

Вид транспорта	Достоинства	Недостатки
1	2	3
Железнодорожный	Высокая провозная и пропускная способность. Независимость от климатических условий, времени года и суток. Высокая регулярность перевозок. Относительно низкие тарифы; значительные скидки для транзитных отправок. Высокая скорость доставки грузов на большие расстояния.	Ограниченное количество перевозчиков. Большие капитальные вложения в производственно-техническую базу. Высокая материалоемкость и энергоемкость перевозок. Низкая доступность к конечным точкам продаж (потребления). Недостаточно высокая сохранность груза.
Морской	Возможность межконтинентальных перевозок. Низкая себестоимость перевозок на дальние расстояния. Высокая провозная и пропускная способность. Низкая капиталоемкость перевозок.	Ограниченность перевозок. Низкая скорость доставки (большое время транзита). Зависимость от географических, навигационных и погодных условий. Необходимость создания сложной портовой инфраструктуры.
Внутренний водный (речной)	Высокие провозные возможности на глубоководных реках и водоемах. Низкая себестоимость перевозок. Низкая капиталоемкость	Ограниченность перевозок. Низкая скорость доставки. Зависимость от неравномерности глубин рек и водоемов, навигационных условий. Сезонность. Недостаточная надежность перевозок и сохранность груза.
Автомобильный	Высокая доступность. Возможность доставки груза «от двери до двери». Высокая маневренность, гибкость, динамичность. Высокая скорость доставки. Возможность использования различных маршрутов и схем доставки. Возможность отправки груза маленькими партиями. Широкие возможности выбора наиболее подходящего перевозчика.	Низкая производительность. Зависимость от погодных и дорожных условий. Относительно высокая себестоимость перевозок на большие расстояния. Недостаточная экологическая чистота.
Воздушный	Наивысшая скорость доставки груза. Высокая надежность. Наивысшая сохранность груза. Наиболее короткие маршруты перевозок.	Высокая себестоимость перевозок, наивысшие тарифы среди других видов транспорта. Высокая капитале-, материа-ло- и энергоемкость перевозок. Зависимость от погодных условий. Недостаточная географическая доступность.
Трубопроводный	Низкая себестоимость. Высокая производительность (пропускная способность). Высокая сохранность груза. Низкая капиталоемкость.	Ограниченность видов груза (газ, нефтепродукты, эмульсии сырьевых материалов). Недостаточная доступность малых объемов транспортируемых грузов.

Размещено на Allbest.ru

...