Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Конфигурацияны басқаруда (КМ) бағдарламалық қамтамасыз ету мен құжаттамаға енгізілген өзгерістерді (басқа нәрселермен қатар) бақылау қажет. Бұл нұсқаларды басқару деп аталады, ол бір ақпарат бірлігінің әр түрлі нұсқаларын басқарады. Нұсқаларды басқару КМ үшін маңызды болғанымен, оған толыққанды тең келмейді. Синхрондау модельдері, сондай-ақ конфигурацияны басқару модельдері (Фейлер, 1991) деп те аталады, жеке файлдарға бір уақытта, параллель түрде өзгерістер енгізу арқылы нұсқаларды басқаруға мүмкіндік беретін әдістерді сипаттайды.
In configuration management (CM), one has to control (among other things) changes made to software and documentation. This is called revision control, which manages multiple versions of the same unit of information. Although revision control is important to CM, it is not equal to it. Synchronization Models, also known as Configuration Management Models (Feiler, 1991), describe methods to enable revision control through allowing simultaneous, concurrent changes to individual files.
Синхрондау үлгілері
Фейлер (1991) төменде қысқаша сипатталатын төрт түрлі синхронизация модельдері туралы хабарлайды.
Feiler (1991) reports on four different synchronization models, shortly described below.
Шығу/кіру
Тексеру/қабылдау үлгісінде файлдар репозиторийде жеке-жеке сақталады, олар қол жеткізілген кезде тексеріліп алынады және өзгерістер енгізілген кезде қайта тексеріледі. Бұл репозиторий файлдардың бірнеше нұсқасын сақтай алады. Бұл файлдар құжаттама немесе бастапқы код болуы мүмкін, сонымен қатар файлдар жиынтығы да болуы мүмкін, сондықтан енді конфигурациялық элемент (CI) термині қолданылады. Бір уақытта жасалған өзгерістерден туындаған қақтығыстарды болдырмау үшін негізгі механизм – құлыптау.
In the check out/check in model, files are stored individually in a repository from which they are checked out whenever the files are accessed, and checked in when they have changed. This repository can store multiple versions of the files. Because these files can be documentation or source code, but can also be a collection of files, the term Configuration item (CI) will be used from now on. The basic mechanism used to prevent conflicts by simultaneous modifications is that of locking.
Құрамы
Композициялық модель – тексеру/есепке алу моделінің кеңейтілген түрі. Бұл модель әзірлеушілерге жеке файлдардың орнына конфигурациялармен жұмыс істеуге мүмкіндік береді. Тексеру/есепке алу моделі композициялық модельде толыққанды бейнеленгенімен, конфигурацияларды басқаруды жақсарту арқылы жаңартудың әртүрлі стратегияларын қолдануға болады. Конфигурация – жүйелік модель және нұсқа таңдау ережелері негізінде құрастырылады. Жүйелік модель қолданылатын файлдарды анықтайды, ал нұсқа таңдау ережелері файлдардың қай нұсқасын (мысалы, ең соңғы нұсқаларын немесе белгілі бір даму кезеңін) анықтайды.
The composition model is an extension on the check out/check in model. This model allows developers to think in configurations instead of individual files. Although the complete check out/check in model is represented in the composition model, it enables the use of different strategies for updating through the use of improved support for the management of configurations. A configuration is defined as being built up from a system model and version selection rules. The system model determines which files are used, while the version selection rules determine which version of the files (e. g. the latest versions or of a certain development state).
Ұзақ операциялар
Ұзақ транзакциялар моделі жүйені логикалық өзгерістерден құралғандығын қарастыра отырып, кең көзқарас ұсынады. Оның негізгі назары осы өзгерістерді үйлестіру мен интеграциялауға бағытталған. Қорыта айтқанда, ол конфигурация нұсқаларын және файл нұсқаларын қолданады. Конфигурация өзгерту талабы негізінде жасалады, ал бұл талап жеке сақталады. Осы конфигурациядағы файлдарды тексеру/қолдану (check out/check in) моделі арқылы синхрондауға болады. Өзгеріс аяқталған соң, толық конфигурация репозиторийге сақталып, басқа өзгерістермен біріктіріледі.
The long transactions model takes a broader approach by assuming that a system is built up out of logical changes. Its focus is on the coordination and integration of these changes. Basically, it uses versions of configurations and versions of files. A configuration is created based on a change request which is stored separately. Files in this configuration can be synchronized using the check out/check in model. When the change is completed, the complete configuration is stored back into the repository and integrated with other changes.
Өзгеріс жиынтығы
Өзгерістер жиынтығы моделі де өзгеріс сұранымдары негізінде жұмыс істейді және ұзақ транзакциялар моделімен көптеген ортақ белгілері бар. Дегенмен, ол өзгерістердің бастапқы негізі ретінде белгілі бір конфигурациядан басталады. Бұл, кейіннен келіп түсетін тәуелсіз өзгеріс сұранымдарына сәйкес өзгертіледі. Өнімнің жаңа конфигурациялары бастапқы нұсқаға тәуелсіз сақталған өзгерістер жиынтығын қолдану арқылы құрылады. Осы жазбада мета-модельді (процесс деректерінің схемасы) қоса алғанда, тексеру/қайтару синхрондау моделі қарастырылады. Тексеру/қайтару моделі жоғарыда талқыланған басқа модельдердің құрамында болғандықтан, оны одан әрі кеңейте түсеміз. Толыққанды талқыланбаған мәселелер – қалған үш синхрондау моделі және КИ-ді (конфигурациялық элементтерді) нақты өңдеу, сондай-ақ осыған қатысты әдістер.
The change set model also works based on change requests and has a lot in common with the long transactions model. However, it starts with a certain configuration as the basis for changes. This is then changed according to the independent change requests that come in. New configurations of the product are then created by applying sets of the independently stored changes on the baseline version. This entry covers the check out/check in synchronization model, including a meta model (a process data diagram). Because the check out/check in model is also included as a part of the other models discussed above, it is therefore further elaborated upon. Issues that are not discussed in detail are the three remaining synchronization models and the actual editing of CIs together with the methods related to this.
Сөздік
Нысанның анықтамасыVersionНысан – объектінің немесе ұғымның алдыңғы күйінен немесе жағдайынан өзгеше болатын күйі. Конфигурация элементі – нұсқауды басқаруға берілген бағдарламалық қамтамасыз ету элементі немесе құжат. КИ тобы да КИ ретінде анықталуы мүмкін (Crnkovic және басқалар, 2003). Конфигурация элементтерінің тарихы – нұсқауды белгілеуді жеңілдетуге арналған тұжырымдама. Версияға тән атрибуттарды барлық нұсқаларға ортақ атрибуттардан бөліп алады (Ван де Верд, 2005). Құжат – бағдарламалық жасақтаманы жасаудың көптеген түрлері. Бағдарламалық жасақтаманың архитектурасын, техникалық құжаттаманы, пайдаланушы нұсқаулықтарын және т.б. сипаттайтын құжаттарды қарастырыңыз. Көздік код файлы – адам оқи алатын компьютерлік бағдарламалау тілінде жазылған операторлардың кез келген тізбегі. Компьютерлік бағдарламаның көздік коды – адам оқи алатын формадан эквивалентті компьютерлік орындалатын формаға түрлендірілетін файлдар жиынтығы. Қойма – қойманы «жәшік» деп те атайды. Қоймада конфигурация элементінің бір толық нұсқасы ғана болады. Нұсқалар арасындағы айырмашылықтар әдетте дельта алгоритмі арқылы сақталады (Crnkovic, Asklund & Persson Dahlqvist, 2003). Нұсқаларды ұйымдастыру – КИ нұсқаларын әр түрлі жолдармен ұйымдастыруға болады. Бұл нұсқаларды ұйымдастыруды сипаттайтын ұғымдардың бастауы (Crnkovic және басқалар, 2003). Тармақ – параллель даму жолдары ретінде ұйымдастырылған нұсқалар (Crnkovic және басқалар, 2003). Түзету – реттілікпен ұйымдастырылған нұсқалар (Crnkovic және басқалар, 2003). Даму күйі – бағдарламалық жасақтаманың дамуы қаншалықты алға жылжуын және одан әрі қаншалықты даму қажет екенін көрсетеді. Өнімнің әрбір негізгі нұсқасы әдетте жаңа мүмкіндіктер қосылған кездегі кезеңнен өтеді (альфа кезеңі/күйі), содан кейін белсенді түрде түзетулер жасалатын кезеңнен (бета кезеңі/күйі) және соңында барлық маңызды қателер жойылған кездегі кезеңнен (тұрақты кезеңі/күйі) өтеді.
Concept DefinitionVersionA version is a state of an object or concept that varies from its previous state or condition. Configuration itemAn element of software or a document placed under version control. A group of CIs can also be defined as a CI (Crnkovic et al., 2003). Configuration item historyA concept to facilitate version stamping. Splits version specific attributes from attributes common to all versions (Van de Weerd, 2005)DocumentMany types of documentation are part of software engineering. Consider documents that describe the software architecture, technical documentation, user manuals, etc. Source code fileA source code file contains any series of statements written in some human readable computer programming language. A computer program's source code is the collection of files that can be converted from human readable form to an equivalent computer executable form. RepositoryA repository is also called a vault. A repository contains only one complete version of a configuration item. Differences between versions are usually stored using a delta algorithm (Crnkovic, Asklund & Persson Dahlqvist, 2003). Versioning organizationVersions of a CI may be organized in a number of different ways. This is the parent for the concepts that describe the organization of versions (Crnkovic et al., 2003). BranchVersions organized as parallel development lines (Crnkovic et al., 2003). RevisionVersions organized in a sequence (Crnkovic et al., 2003). Development stateExpresses how the development of a piece of software has progressed and how much further development it may require. Each major version of a product usually goes through a stage when new features are added (alpha stage / state), then a stage when it is actively debugged (beta stage / state), and finally a stage when all important bugs have been removed (stable stage / state).
Шегіну/келу үлгісін әзірлеу
Бұл бөлімде тіркелу/шығу синхрондау моделі туралы толық мәлімет берілген.
This section contains an elaboration on the check out/check in synchronization model.
Процесс-деректер диаграммасы
Жоғарыда көрсетілген процестік деректер диаграммасында тексеру/тексеру синхрондау моделінде қолданылатын әртүрлі ұғымдар және олардың орындалатын іс-әрекеттермен байланысы сипатталған. Метадеректер моделінің (суреттің оң жағында) орталық бөлігі – Конфигурациялық элемент. Ол бір немесе бірнеше репозиторийлерде сақталады және мысалы, бастапқы код файлы немесе басқа Конфигурациялық элементтердің жиынтығы болуы мүмкін. Репозиторийде файлдардың бірнеше тармақтары мен редакциялары болуы мүмкін. Бұл өз кезегінде конфигурациялық элементтерден тұрады. Мета-процесс моделі (суреттің сол жағында) тексеру және тексеру іс-әрекеттерінің процесін сипаттайды. Іс-әрекеттер төмендегі кестеде түсіндірілген.
The process data diagram above describes the different concepts that are applicable in the check out/check in synchronization model and their relation to the activities that take place. Central to the meta data model (right side of the figure) is the Configuration Item. This is stored in one or more repositories and can for example be a source code file or a collection of other CIs. The repository can contain multiple branches and revisions of files. These in turn consist of configuration items. The meta process model (left side of the figure) describes the process of the check out and check in activities. The activities are explained in the table of activities below. Activity Sub activity DefinitionCheck Out Files are not read or changed directly from the repository. Checking out describes these activities. Copy CI A particular version of a CI is copied from the repository. Lock CIIf write access is required and if the CI is not already locked by someone else, the CI is locked. Otherwise the CI cannot be written back to the repository (read only access). Modify CIThe person editing the CI makes changes to it. This is out of the scope of the current meta model regarding version management. Check InThe CI needs to be placed back into the repository. Checking in describes these activities. Select versioning strategyThe new CI has to be placed back in the repository using a versioning strategy. This describes the selection of the strategy used to place the CI back into the repository. Create branchThe CI is selected to be the start of a new branch. Create revisionThe CI is selected to be a revision of another CI. Select development stateThe CI is determined to be of a certain development state. Write CIThe CI is stored in the repository. Unlock CIThe CI is unlocked.
Іс-әрекет | Қосалқы іс-әрекет | Анықтама
------- | -------- | --------
Check Out | | Файлдар репозиторийден тікелей оқылмайды немесе өзгертілмейді. Тексеру осы іс-әрекеттерді сипаттайды.
КИ көшірмесі | | КИ-нің белгілі бір нұсқасы репозиторийден көшіріледі.
КИ-ді құлыптау | | Егер жазуға қол жеткізу қажет болса және КИ басқа біреумен құлыпталмаған болса, КИ құлыпталады. Әйтпесе, КИ-ді репозиторийге қайта жазу мүмкін емес (тек оқуға қол жеткізіледі).
КИ-ді өңдеу | | КИ-ді өңдейтін адам оған өзгерістер енгізеді. Бұл нұсқаны басқаруға қатысты ағымдағы метамодельдің шеңберінен тыс.
Check In | | КИ репозиторийге қайта орналастырылуы керек. Тексеру осы іс-әрекеттерді сипаттайды.
Версияны басқару стратегиясын таңдау | | Жаңа КИ версияны басқару стратегиясын қолдана отырып репозиторийге қайта орналастырылуы керек. Бұл КИ-ді репозиторийге қайта орналастыру үшін қолданылатын стратегияны таңдауды сипаттайды.
Жаңа тармақ құру | | КИ жаңа тармақтың басталуы ретінде таңдалады.
Жаңа редакция құру | | КИ басқа КИ-дің редакциясы ретінде таңдалады.
Даму күйін таңдау | | КИ белгілі бір даму күйінде деп анықталады.
КИ-ді жазу | | КИ репозиторийде сақталады.
КИ-ді ашу | | КИ-дің құлпы ашылады.
The process data diagram above describes the different concepts that are applicable in the check out/check in synchronization model and their relation to the activities that take place. Central to the meta data model (right side of the figure) is the Configuration Item. This is stored in one or more repositories and can for example be a source code file or a collection of other CIs. The repository can contain multiple branches and revisions of files. These in turn consist of configuration items. The meta process model (left side of the figure) describes the process of the check out and check in activities. The activities are explained in the table of activities below. Activity Sub activity DefinitionCheck Out Files are not read or changed directly from the repository. Checking out describes these activities. Copy CI A particular version of a CI is copied from the repository. Lock CIIf write access is required and if the CI is not already locked by someone else, the CI is locked. Otherwise the CI cannot be written back to the repository (read only access). Modify CIThe person editing the CI makes changes to it. This is out of the scope of the current meta model regarding version management. Check InThe CI needs to be placed back into the repository. Checking in describes these activities. Select versioning strategyThe new CI has to be placed back in the repository using a versioning strategy. This describes the selection of the strategy used to place the CI back into the repository. Create branchThe CI is selected to be the start of a new branch. Create revisionThe CI is selected to be a revision of another CI. Select development stateThe CI is determined to be of a certain development state. Write CIThe CI is stored in the repository. Unlock CIThe CI is unlocked.
Бағалау
Feiler (1991) тексеру/тексеру синхрондау моделін бағалады. Оның ең айқын артықшылығы – пайдалану және түсіну оңайдығы. Дегенмен, осы қарапайымдық конфигурацияларды басқарудағы кемшіліктерге, мысалы, өнім нұсқаларын қадағалауда және бірнеше логикалық байланысты файлдардың нұсқа тарихын тексеруде көрінеді. Көптеген дамытушылармен жұмыс істегенде файлдарды құлыптау арқылы кезек беру механизмі нақты проблема тудырады, себебі құлыпталған файлдарды басқалар өзгерте алмайды.
Feiler (1991) evaluated the check out/check in synchronization model. It has the clear advantage that it's easy to use and understand. However, this simplicity results in a lack of management of configurations, such as product version tracking and checking version history across multiple logically connected files. The turn taking mechanism of locking is a real problem as well when working with many developers, as these files cannot be edited by others once it has been locked.
Мысал
Тексеру/текстілеу синхрондау моделін түсіндіру үшін, осы бөлімде осы процестің қалай жұмыс істейтініне мысал келтірілген. Төмендегі суретте КИ-дың күй өзгерту диаграммасы көрсетілген. КИ алғаш рет жасалғанда, ол өзгертіліп, репозиторийде сақталады. Біреу КИ-ды ашуды сұрағанда, ол әзірлеушінің жеке компьютеріне көшіріледі (ескерту: кейбір жүйелерде өңдеу тікелей репозиторийде жүзеге асырылады. Дегенмен, көшіру қадамы – классикалық тексеру/текстілеу әдісі). Егер әзірлеуші де КИ-ды өңдеткісі келсе, ол құлыптауды сұрайды. Бұл КИ-ды ашу туралы сұраумен бірге, оны оқығаннан кейін де жасалуы мүмкін. Егер КИ әлі құлыпталмаған болса, құлыптау қойылады және оны әзірлеуші өзгерте алады. Өзгерістер енгізілгеннен кейін, ол қайтадан репозиторийге сақталады және құлыптан босатылады. Енді, жоғарыда айтылған әзірлеуші репозиторийдегі КИ-ды өңдеу үстінде деп есептейік. Сіз репозиторийден КИ-ды ашуды қалайсыз, сондықтан ол сіздің жеке дискіңізге көшіріледі. Сіз оны оқып, өзгертуді қалаған нәрселерді табасыз, сондықтан оны өңдеуге рұқсат сұрайсыз. Бірақ, КИ әлдеқашан құлыпталған, сондықтан оның босатылуын күтуіңіз керек немесе файлды жабылып, басқа КИ-ға көшуіңіз керек.
To illustrate the check out/check in synchronization model, this section contains an example of how this process works. The figure below contains a state transition diagram of a CI. When a CI is first created, it is modified and stored in the repository. When someone requests to open the CI, it is first copied to the local machine of the developer (note: there are systems where editing occurs directly in the repository. The copy step however is the classic check out/check in way). When that developer also wants to edit the CI, it requests a lock. This can be done directly at the request of opening a CI, but also after some time of reading it. When the CI is not locked yet, a lock is applied and it can be modified by the developer. After modifications have been done, it is stored back in the repository and unlocked. Now, assume that the developer that was just discussed is in the process of editing a CI that is already in the repository. You want to open a CI from the repository and so it is copied to your local drive. You start reading it and find some things you wish to change, so you request to edit it. However, the CI is already locked and you will have to wait for it to be unlocked or close the file and proceed to another one.