3. Приведите классификацию case-средств по типам и категориям.
Цель конфигурационного управления (КУ) - обеспечить управляемость и контролируемость процессов разработки и сопровождения ПО.
PVCS Version Manager предназначен для управления всеми компонентами проекта и ведения планомерной многоверсионной и многоплатформенной разработки силами команды разработчиков в условиях одной или нескольких локальных сетей. PVCS Version Manager предназначен для использования в рабочих группах. Система блокировок, реализованная в PVCS Version Manager позволяет предотвратить одновременное внесение изменений в один и тот же файл. Доступ к архивам PVCS Version Manager возможен не только через сам Version Manager, но и из более чем 50 инструментальных средств, в том числе MS Visual C и MS Visual Basic, Uniface, PowerBuilder, SQL Windows, JAM, Delphi, Paradox и др. Результатом работы PVCS Version Manager является созданный средствами файловой системы репозиторий, хранящий в компактной форме все рабочие версии программного продукта вместе с необходимыми комментариями и метками.
PVCS Tracker - специализированная надстройка над офисной электронной почтой, предназначенная для обработки сообщений об ошибках в продукте, доставке их исполнителям и контроля за исполнением. Интеграция с PVCS Version Manager дает возможность связывать с сообщениями те или иные компоненты проекта. Отчетные возможности PVCS Tracker включают множество разновидностей графиков и диаграмм, отражающих состояние проекта и процесса его отладки, срезы по различным компонентам проекта, разработчикам и тестировщикам. С их помощью можно наглядно показать текущее состояние работы над проектом и ее временные тенденции. PVCS Tracker предназначен для использования в рабочих группах, объединенных в общую сеть.
Персонал, работающий с PVCS Tracker делится на пять групп в зависимости от их обязанностей: пользователи, разработчики, группа тестирования и контроля качества, группа технической поддержки и сопровождения, управленческий персонал. Этим пяти группам персонала соответствуют пять предопределенных групп PVCS Tracker:
пользователи (Submitters)- имеют ограниченные права на внесение замечаний и сообщений об ошибках в базу данных PVCS Tracker;
разработчики (Development Engineers)- имеют право производить основные операции с требованиями и замечаниями в базе данных PVCS Tracker. Если разработчики делятся на подгруппы, то для каждой подгруппы могут быть заданы отдельные списки прав доступа;
тестировщики (Quality Engineers)- имеют право производить основные операции с требованиями и замечаниями;
сопровождение (Support Engineers)- имеют право вносить любые замечания, требования и рекомендации в базу данных, но не имеют прав по распределению работ и изменению их приоритетности и сроков исполнения;
руководители (Managers)- имеют право распределять работы между исполнителями и принимать решения о их надлежащем исполнении. Руководителям разных групп могут заданы различные права доступа к базе данных PVCS Tracker.
Требование или замечание поступающее в PVCS Tracker проходит четыре этапа обработки:
регистрация - внесение замечания в базу данных;
распределение - назначение ответственного исполнителя и сроков исполнения;
исполнение - устранение замечания, которое в свою очередь может вызвать дополнительные замечания или требования на дополнительные работы;
приемка - приемка работ и снятие их с контроля или направление на доработку.
PVCS Configuration Builder предназначен для сборки окончательного продукта из компонент проекта. PVCS Configuration Builder позволяет описывать процесс сборки как на стандартном языке MAKE, так и на собственном внутреннем языке, имеющем существенно большие возможности. PVCS Configuration Builder позволяет осуществлять сборку программного продукта на основании файлов, хранящихся в репозитории PVCS Version Manager.
Обычная процедура сборки программного продукта с помощью PVCS Configuration Builder состоит из трех шагов:
строится файл зависимостей между исходными модулями;
в полученный файл вносятся изменения с целью его настройки и оптимизации;
осуществляется сборка программного продукта из исходных модулей.
PVCS Notify обеспечивает автоматическую рассылку сообщений об ошибках из базы данных пакета PVCS Tracker по рабочим станциям назначения. PVCS Notify настраивается из среды PVCS Tracker. Настройка включает в себя определение интервала времени, через который PVCS Notify проверяет содержимое базы данных, определение критериев отбора записей для рассылки уведомлений, определение списков адресов для рассылки. После настройки PVCS Notify начинает работу в автономном режиме, автоматически рассылая уведомления об изменениях в базе данных PVCS Tracker. Результатом работы PVCS Notify являются оформленные в соответствии с одним из стандартов почтовые сообщения, готовые для рассылки посредством системы электронной почты.
Билет 20
1) Встроенный язык программирования 1С:Предприятие —язык программирования, который используется в семействе программ «1С:Предприятие». Данный язык является предварительно компилируемым предметно-ориентированным языком высокого уровня.
Средой исполнения языка является программная платформа «1С:Предприятие». Визуальная среда разработки («Конфигуратор») является неотъемлемой частью пакета программ «1С:Предприятие».
Диалекты языка для платформ 1С 7 версий (7.0, 7.5, 7.7) совместимы «снизу вверх» с незначительными исключениями. Языки для платформ 1С:7х и 1С:8х совместимы по основным операторам, но значительно отличаются в работе с прикладными объектами, вследствие чего перенос кода из 1С:7х в 1С:8х не имеет смысла.
Встроенный язык 1С:8 наиболее подобен по своему синтаксису языку Visual Basic.
Проекты на встроенном языке 1С:Предприятия называются конфигурациями. Распространение (продажа) и внедрение таких конфигураций — это основная коммерческая деятельность фирм-партнёров 1С.
Рабочее название языка — «1Сик» («одинэсик») — очень быстро исчезло из официальных источников. Сейчас при упоминании этого языка в письменных документах нужно писать 1С Язык программирования. Сейчас язык не имеет никакого названия, которое можно было бы произнести устно. Впрочем часто этот язык называют «встроенный язык», в контексте обсуждения 1С:Предприятия.
Рассмотрим обычный сетевой вариант реализации Торговли 1С. Она работает на файл-серверном принципе, это значит что обработка данных производится вычислительными мощностями данной рабочей станции, а сервер является ничем ином как дисковое устройство с хранящимся на нем файлом базы данных. Объясню, что при выполнении задачи, например формирование отчета, фрагмент базы данных (из которого будут отбираться данные для этого отчета) по сети передается на рабочую станцию (запросившую формирование отчета) и обрабатывается непосредственно процессором этой рабочей станции.
2) В производственной структуре каждое из подразделений выполняет свои особые функции (например, производство, финансы, сбыт и кадры) на оперативном уровне. Каждое подразделение в первую очередь преследует свои цели, а не корпоративные интересы компании. Подразделения, разделенные по видам производимой продукции, обычно более мелкие, что способствует большей координации между функциональными подразделениями.
Производственная структура также обладает гибкостью и повышает способность организации приспособиться к конкурентным изменениям в обстановке (то есть когда время от времени необходимо быстрое изменение вида продукта по мере изменения вкусов потребителей). В производственной структуре принятие решений децентрализуется по мере того, как полномочия передаются вниз по иерархической лестнице организации.
Обычно организация начинает свою деятельность в пределах функциональной структуры и может в результате диверсификации продукции смещаться к производственной структуре. Во многих отношениях производственная структура более подходит для решения тех проблем, которые возникают в организациях с функциональной структурой при определенных условиях (ранее это отмечалось как слабые стороны) и в связи с необходимостью справиться с диверсификацией.
Существующие примеры организаций со структурой подобного типа имеют тенденцию к крупным размерам. Джонсон и Скулз (1993) считают, что эта структура является наиболее популярной из принятых в промышленных компаниях, а также компаниях розничной торговли, таких как "Сэйнсбери" и "Маркс и Спенсер".
3) Общая характеристика Rational Rose Rational Rose-это программный пакет для визуального объектно-ориентированного моделирования систем на основе классов и их взаимодействия, а проще это визуальный редактор, позволяющий моделировать программные системы любой сложности на основе графических диаграмм языка UML (UnifiedModelingLanguage). Язык UML кардинально отличается от таких языков программирования как, например, Visual C++ или Visual Basic и предназначен для описания моделей; причем для работы с этим языком используется специальные редакторы диаграмм, такие как Rational Rose. Этот язык слишком сложен, чтобы оперировать им вручную. К счастью, пользователь пакета Rational Rose полностью огражден от ручного ведения кода, и Rational Rose сам создает и сохраняет по визуальным диаграммам все, что необходимо. UML не зависит от объектно-ориентированных языков программирования и может поддерживать любой из них. Этот язык также не зависит от используемой методологии разработки проекта, и созданные на UML диаграммы выразительны и понятны для всех разработчиков, вовлеченных в проект, причем, что немаловажно, не только в момент разработки, но и много месяцев спустя. UML является открытым и обладает средствами расширения базового ядра. На UML можно содержательно описывать классы, объекты и компоненты в различных предметных областях, часто сильно отличающихся друг от друга. Однако пакет Rational Rose поддерживает не только UML, но и другие нотации создания диаграмм, такие как ОМТ или Booch. Мощный толчок CASE-средства получили в пору внедрения объектно-ориентированной технологии разработки программного обеспечения. Старые технологии разработки программ «сверху им из» уже не могли справиться с все усложняющимися и труднообозримыми программными комплексами. Сегодня Rational Rose лидирует среди других CASE-средств, и это не случайно. То, что этот пакет позволяет создавать сложные программные системы от замысла до создания исходного кода, привлекает не только проектировщиков систем, но и программистов-разработчиков. За рубежом изза сильной конкуренции между фирмами-разработчиками программ ни один, даже небольшой программный проект, не обходится без применения CASE-средств. Уже более 50 тысяч больших и малых компаний по всему миру используют Rational Rose для разработки программных систем.
Возможности Rational Rose Инструменты компании Rational Software как нельзя лучше подходят для объектно-ориентированной разработки программ от замысла до реализации в коде. Rational Rose в соединении с другими программными пакетами приобретает свою неповторимую мощь: в сочетании со средствами документирования (Rational SoDA) он может давать полное представление о проекте. Полностью интегрируясь с Microsoft Visual Studio, этот пакет пет возможность получать исходный код взаимодействующих классов и строить визуальные модели по уже написанному исходному коду.
Преимущества от применения Rational Rose значительны и состоят в:
увеличении сокращении цикла разработки приложения «заказчик программист заказчик»;
продуктивности работы программистов: меньше ручного кодирования меньше ошибок, меньше ошибок меньше отладки, меньше отладки больше продуктивность;
улучшении потребительских качеств создаваемых программ за счет ориентации на пользователей и бизнес;
способности вести большие проекты и группы проектов;
возможности повторного использования уже созданного ПО за счет упора на разбор их архитектуры и компонентов;
язык UML служит универсальным «мостиком» между разработчиками из разных отделов.
Диаграммы Rational Rose В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах:
Use case diagram (диаграммы сценариев);
Deployment diagram (диаграммы топологии);
Statechart diagram (диаграммы состояний);
Activity diagram (диаграммы активности); 'Interaction diagram (диаграммы взаимодействия);
Sequencediagram(диаграммы последовательностей действий);
Collaboration diagram (диаграммы сотрудничества);
Class diagram (диаграммы классов);
Component diagram (диаграммы компонент).
Use case diagram (диаграммы сценариев) Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Usecaseэто описание сценария поведения, которому следуют действующие лица (Actors). Данный тип диаграмм используется при описании бизнес-процессов автоматизируемой предметной области, определений требований к будущей программной системе. Отражает объекты как системы, так и предметной области, и задачи, ими выполняемые.
Deployment diagram (диаграммы топологии) Этот вид диаграмм предназначен для анализа аппаратной части системы. В прямом переводе с английского Deploymentозначает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм. Для каждой модели создается только одна такая диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения. Обычно этот тип диаграмм используется в самом начале проектирования системы для анализа аппаратных средств, на которых она будет эксплуатироваться.
State Machine diagram (диаграммы состояний) Каждый объект системы, обладающий определенным поведением, может находиться в определенных состояниях, переходить из состояния в состояние, совершая определенные действия в процессе реализации сценария поведения объекта. Поведение большинства объектов реальных систем можно представить с точки зрения теории конечных автоматов, т.е. поведение объекта отражается в его состояниях, и данный тип диаграмм позволяет отразить это графически. Для этого используется два вида диаграмм: Statechartdiagram(диаграмма состояний) и Activitydiagram(диаграмма активности).
Statechart diagram (диаграмма состояний) Диаграмма состояний (Statechart) предназначена для отображения состояний объектов системы, имеющих сложную модель поведения. Это одна из двух диаграмм StateMachine, доступ к которой осуществляется из одного пункта меню.
Activity diagram (диаграммы активности) Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activitydiagramв том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов, а также проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.
Interaction diagram (диаграммы взаимодействия) Этот тип диаграмм включает в себя Sequencediagram(диаграммы последовательностей действий) и Collaborationdiagram(диаграммы сотрудничества), позволяющие с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Sequence diagram (диаграммы последовательностей действий) Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектам и серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов. Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами, и кроме этого не акцентирует внимание на конкретном взаимодействии; главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaborationdiagram.
Collaboration diagram (диаграммы сотрудничества) Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта, и типы этих сообщений. По причине того, что диаграммы Sequenceи Collaborationявляются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequenceдиаграммы диаграмму Collaborationи наоборот, а также производит автоматическую синхронизацию этих диаграмм.
Class diagram (диаграммы классов) Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на которой отображаются объекты системы. Rational Rose позволяет создавать классы при помощи данного типа диаграмм в различных нотациях.
Component diagram (диаграммы компонентов) Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей. При проектировании больших систем может оказаться, что система должна быть разложена на несколько сотен или даже тысяч компонентов, и этот тип диаграмм позволяет не потеряться в обилии модулей и их связей. Для создания систем различных предметных областей общий порядок работы может несколько отличаться от приведенного, поэтому при разработке другой системы необходимо внести в него соответствующие изменения. Для создания программной системы нашего класса будем использовать описанный ниже порядок работы. В первую очередь произведем анализ списка операций, которые будет выполнять система, и определим список объектов системы, которые данные функции выполняют. Таким образом, определим требования к системе и границы предметной области. Для этого будем использовать диаграммы Usecase. Затем, еще до окончательной детализации сценариев поведения, произведем анализ аппаратной части системы при помощи Deploymentдиаграммы. Это скорее задача системного анализа, чем практическая. В общем случае она позволит определиться в таких вопросах как технологичность и стоимость системы, а также определить набор аппаратных средств, на которых предстоит эксплуатировать систему. Возможно, именно аппаратные средства внесут свои коррективы, ограничения или дополнительные требования к создаваемому программному обеспечению. Затем определим список классов, которые должны присутствовать в системе, пока без конкретной детализации и подробного описания действий. Для этого будем использовать диаграмму классов (Classdiagram). После заведения в системе необходимых классов определим поведение конкретных классов при помощи диаграмм Statechartdiagram(диаграмма состояний) и Activitydiagram(диаграммы активности). Дальнейшая детализация взаимодействия классов будет производиться при помощи Sequencediagram(диаграммы последовательностей действий), Collaborationdiagram(диаграммы сотрудничества). На основании производимых классами действий создадим окончательную иерархию классов системы при помощи диаграммы классов (Classdiagram) и определим компоненты, в которые эти классы необходимо включить при помощи диаграммы компонентов (Componentdiagram).
Разработка это итерационный процесс. Нельзя за один раз создать полный проект системы. Придется многократно возвращаться к уже созданным диаграммам и вносить в них изменения
Билет №21
1.Дайте описание принципа работы двухзвенной клиент-серверной архитектуре ИС.
Существуют два главных звена построения системы - клиентская программа и программа сервера базы данных. Следует заметить, вся обработка информации на компьютере-сервере может осуществляться исключительно языковыми средствами SQL-сервера. А средства эти ограничены. По сути, делается попытка (часто очень успешная) заставить специализированную программу хранения данных (SQL-сервер) выполнять типично прикладные задачи. Но есть решение получше:
Если бы прикладные программы (клиенты) обращались со своими прикладными запросами не к серверу базы данных, а к специализированному серверу, а тот уже обращался к серверу базы данных, то можно было бы избежать ряда проблем двухзвенной архитектуры.
Сервер приложений - это специальная программа, предоставляющая прикладные сервисы для рабочей станции и реализующая их своими вычислительными возможностями, а также путем обращения к серверу базы данных (SQL-серверу). То есть клиентская программа может общаться только с сервером приложений, который в свою очередь общается с сервером базы данных. При этом клиентская программа совершенно ничего не знает про базу данных - ни где хранится, ни какой программой управляется. На клиентских компьютерах устанавливается только программное обеспечение клиентской программы и средства связи с сервером приложений.
2. Дайте описание Матричной структуре предприятия.
в реальном мире не существует чисто функциональных, производственных или региональных структур. Наиболее современным достижением в структуре организации является матричная структура, представляющая из себя комбинацию этих структурных форм, в особенности функциональной и производственной. Матричная структура подходит организации, структура которой имеет множество точек сосредоточения и должна ориентироваться как на продукте, так и на функции одновременно.
Например, если организация с растущим количеством различных производимых продуктов хотела бы сохранить преимущества функциональной структуры и понимала невыгодность наличия всех управленческих функций во всех производственных подразделениях в цеховой структуре, матричная структура, как показано на приведенном ниже рисунке 1, в большей мере соответствовала бы потребностям организации
Матричная структура особенно соответствует работе с конкретными проектами. Члены организации распределяются по конкретным проектам в качестве руководителей проекта, оставаясь ответственными в этой структуре за функциональное или производственное подразделение организации.
Отличительной чертой матричных структур является то, что некоторые служащие, как видно из рис. 1, подчиняются сразу двум начальникам, что, похоже, не отвечает традиционным принципам управления. Например, сотрудник Х в финансовом управлении подчиняется управляющему проектом B и в конечном счете финансовому директору. Сотрудник Y подчиняется управляющему проектом А, а также директору по сбыту. Подобная практика может создавать конфликтные ситуации которые необходимо решать, а также может привести к тому, что служащие организации с матричной структурой будут тратить много времени на совещания.
Матричная структура является наиболее подходящей при следующих условиях:
1.когда возникает проблема распределения недостаточных ресурсов между производимыми продуктами;
2.когда есть давление на два или более критических показателя, таких как техническое качество (финансовая структура) и частое появление новых продуктов (производственная структура);
3.когда обстановка вокруг организации сложна и неопределенна.
3. Приведите классификация моделей разрабатываемого программного обеспечения, используемых на этапе определения спецификаций.
Спецификации представляют собой полное и точное описание функций и ограничений разрабатываемого программного обеспечения. При этом одна часть спецификаций (функциональные) описывает функции разрабатываемого программного обеспечения, а другая часть (эксплуатационные) определяет требования к техническим средствам, надежности, информационной безопасности и т. д.
Определение отражает главные требования к спецификациям. Применительно к функциональным спецификациям подразумевается, что:
требование полноты означает, что спецификации должны содержать всю существенную информацию, где ничего важного не было бы упущено, и отсутствует несущественная информация, например детали реализации, чтобы не препятствовать разработчику в выборе наиболее эффективных решений;
требование точности означает, что спецификации должны однозначно восприниматься как заказчиком, так и разработчиком.
Последнее требование выполнить достаточно сложно в силу того, что естественный язык для описания спецификаций не подходит: даже подробные спецификации на естественном языке не обеспечивают необходимой точности. Точные спецификации можно определить, только разработав некоторую формальную модель разрабатываемого программного обеспечения.
Формальные модели, используемые на этапе определения спецификаций можно разделить на две группы:
модели, зависящие от подхода к разработке (структурного или объектно- ориентированного),
модели, не зависящие от него.
Так диаграммы переходов состояний, которые демонстрируют особенности поведения разрабатываемого программного обеспечения при получении тех или иных сигналов извне, и математические модели предметной области используют при любом подходе к разработке.
В рамках структурного подхода на этапе анализа и определения спецификаций используют три типа моделей:
ориентированные на функции,
ориентированные на данные
и ориентированные на потоки данных
Так методологии структурного анализа и проектирования, основанные на моделировании потоков данных, обычно используют комплексное представление проектируемого программного обеспечения в виде совокупности моделей:
диаграмм потоков данных (DFD - Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;
диаграмм «сущность-связь» (ERD - Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы;
диаграмм переходов состояний (STD - State Transition Diagrams), характеризующих поведение системы во времени;
спецификаций процессов;
словаря терминов.
Билет №22