GIT – призначення, особливості, використання.
Система контролю версій - це система, що записує зміни у файл або набір файлів протягом деякого часу, так що ви зможете повернутися до певної версії пізнише. Як приклад, в цій книзі, для файлів, що знаходяться під контролем версій, буде використовуватися код програмного забезпечення, хоча насправді ви можете використовувати контроль версій практично для будь-яких типів файлів.
Якщо ви графічний або веб-дизайнер і хочете зберегти кожну версію зображення або макета (швидше за все, захочете), система контролю версій (далі СКВ) якраз те, що потрібно. Вона дозволяє повернути файли до стану, в якому вони були до змін, повернути весь проект до попереднього стану, побачити зміни, побачити, хто останній міняв щось і спровокував проблему, хто вказав на проблему і коли, та багато іншого. Використання СКВ також в цілому означає, що, якщо ви зламали щось або втратили файли, ви просто можете все виправити. Крім того, ви отримаєте все це за дуже невеликі накладні витрати
Суть структурного (функціонального) підходу до проектування ІС
Сутність структурного підходу до розробки ІС полягає в її декомпозиції (розбитті) на автоматизує функції: система розбивається на функціональні підсистеми, які в свою чергу діляться на підфункції, що підрозділяються на завдання й так далі. Процес розбиття триває аж до конкретних процедур. При цьому автоматизована система зберігає цілісне представлення, у якому всі складові компоненти взаємопов'язані. При розробці системи "знизу-вверх" від окремих завдань до всієї системи цілісність втрачається, виникають проблеми при інформаційній стикування окремих компонентів.
Усі найбільш поширені методології структурного підходу базуються на ряді загальних принципів. В якості двох базових принципів використовуються наступні: принцип "розділяй і володарюй" - принцип вирішення складних проблем шляхом їх розбиття на безліч менших незалежних задач, легких для розуміння і вирішення; принцип ієрархічного упорядкування - принцип організації складових частин проблеми в ієрархічні деревоподібні структури з додаванням нових деталей на кожному рівні.
Виділення двох базових принципів не означає, що інші принципи є другорядними, оскільки ігнорування будь-якого з них може призвести до непередбачуваних наслідків (в тому числі і до провалу всього проекту). Основними з цих принципів є наступні: принцип абстрагування - полягає у виділенні істотних аспектів системи і відволікання від несуттєвих; принцип формалізації - полягає в необхідності суворого методичного підходу до вирішення проблеми; принцип несуперечливості - полягає в обгрунтованості та узгодженості елементів; принцип структурування даних - полягає в тому, що дані повинні бути структуровані і ієрархічно організовані.
У структурному аналізі використовуються в основному дві групи засобів, що ілюструють функції, виконувані системою і відносини між даними. Кожній групі засобів відповідають певні види моделей (діаграм), найбільш поширеними серед яких є наступні: SADT (Structured Analysis and Design Technique) моделі і відповідні функціональні діаграми (підрозділ 2); DFD (Data Flow Diagrams) діаграми потоків даних (підрозділ 3); ERD (Entity-Relationship Diagrams) діаграми "сутність-зв'язок" (підрозділ 4).
На стадії проектування ІС моделі розширюються, уточнюються і доповнюються діаграмами, що відбивають структуру програмного забезпечення: архітектуру ПЗ, структурні схеми програм і діаграми екранних форм.
Перераховані моделі в сукупності дають повний опис ІС незалежно від того, чи є вона існуючої або знову розробляється. Склад діаграм в кожному конкретному випадку залежить від необхідної повноти опису системи
Діаграми кооперації UML
Діаграма кооперації - Collaboration Diagram (в UML 2.0 - Communication Diagram).
кооперація - Фундаментальне поняття в UML, що характеризує взаємодію об'єктів для реалізації деякої функції. Передбачається, що об'єкти при взаємодії обмінюються повідомленнями.
Діаграма кооперації є іншим варіантом діаграми послідовностей.
Переваги діаграми кооперацій:
1) Діаграма кооперацій більш компактна, відображає взаємодію, прив'язуючись до архітектури системи.
2) На ній зручніше розташовувати компоненти і відстежувати потоки подій.
3) Краще видно зв'язок з БД
На діаграмі кооперацій вісь часу відсутня, тому нумерація повідомлень обов'язкове.
Головна особливість діаграми кооперації полягає в можливості графічно представити не тільки послідовність взаємодії, але і всі структурні відносини між об'єктами, які беруть участь в цій взаємодії. Поведінка системи може описуватися на рівні окремих об'єктів, які обмінюються між собою повідомленнями, щоб досягти потрібної мети або реалізувати певний сервіс. Таким чином, за допомогою діаграми кооперації можна описати повний контекст взаємодій як своєрідний часовий "зріз" сукупності об'єктів, які взаємодіють між собою для виконання певного завдання або цілі програмної системи.
Кооперація може бути представлена ??на двох рівнях:
1. На рівні специфікації - показує ролі класифікаторів і ролі асоціацій в розглянутому взаємодії.
2. На рівні прикладів - вказує екземпляри і зв'язки, що утворюють окремі ролі в кооперації.
Діаграма кооперації рівня специфікації показує ролі, які грають беруть участь у взаємодії елементи. Елементами кооперації на цьому рівні є класи і асоціації, які позначають окремі ролі класифікаторів і асоціацію між учасниками кооперації.
Діаграма кооперації рівня прикладів представляється сукупністю об'єктів (екземпляри класів) і зв'язків (екземпляри асоціацій). При цьому зв'язки доповнюються стрілками повідомлень. На даному рівні показуються тільки релевантні об'єкти, т. Е. Мають безпосереднє відношення до реалізації операції або класифікатора. Одна і та ж сукупність об'єктів може брати участь в різних коопераціях. При цьому, в залежності від даної кооперації, можуть змінюватися як властивості окремих об'єктів, так і зв'язку між ними. Саме це відрізняє діаграму кооперації від діаграми класів, на якій повинні бути вказані всі властивості і асоціації між елементами діаграми.
Загальне уявлення кооперації на рівні специфікації використовується на початкових етапах проектування. В подальшому кожна з кооперацій підлягає деталізації на рівні прикладів, на якому розкривається зміст і структура взаємозв'язків її елементів на окремій діаграмі кооперації. При цьому в якості елементів діаграми кооперації виступають об'єкти і зв'язку, доповнені повідомленнями.
Об'єкт (object) є окремим екземпляром класу, який створюється на етапі виконання програми. Він може мати своє власне ім'я і конкретні значення атрибутів. Стосовно об'єктів формат рядка класифікатора доповнюється ім'ям об'єкта і набуває такого вигляду (при цьому вся запис підкреслюється): <Ім'я об'єкта> '/' <Ім'я ролі класифікатора> ':' <Ім'я класифікатора>.
У контексті мови UML всі об'єкти діляться на дві категорії: пасивні та активні. Пасивний об'єкт оперує тільки даними і не може ініціювати діяльність з управління іншими об'єктами, але можуть посилати сигнали в процесі виконання запитів, які вони отримують. Активний об'єкт (active object) має свою власну нитку (thread) управління і може ініціювати діяльність з управління іншими об'єктами. При цьому під ниткою розуміється деякий полегшений потік управління, який може виконуватися паралельно з іншими обчислювальними нитками або нитками управління в межах одного обчислювального процесу або процесу управління.
Зв'язок (link) є екземпляром або прикладом довільної асоціації. Зв'язок як елемент мови UML може мати місце між двома і більше об'єктами. Поруч з лінією в її середній частині може записуватися ім'я відповідної асоціації. Зв'язки не мають власних імен, оскільки повністю ідентичні як екземпляри асоціації. Зв'язок може мати деякі стереотипи, які записуються поруч з одним з її кінців і вказують на особливість реалізації цих питань. У мові UML для цієї мети можуть використовуватися такі стереотипи:
- "Association" - асоціація (передбачається за замовчуванням, тому цей стереотип можна не вказувати).
- "Parameter" - параметр методу. Відповідний об'єкт може бути тільки параметром деякого методу.
- "Local" - локальна змінна методу. Її область видимості обмежена тільки сусіднім об'єктом.
- "Global" - глобальна змінна. Її область видимості поширюється на всю діаграму кооперації.
- "Self - рефлексивна зв'язок об'єкта з самим собою, яка допускає передачу об'єктом повідомлення самому собі. На діаграмі кооперації рефлексивна зв'язок зображується петлею у верхній частині прямокутника об'єкта.
Повідомлення на діаграмі кооперації специфікує комунікацію між двома об'єктами, один з яких передає іншому певну інформацію. При цьому перший об'єкт очікує, що після отримання повідомлення другим об'єктом піде виконання деякого дії. Таким чином, саме повідомлення є причиною або стимулом для початку виконання операцій, відправки сигналів, створення і знищення окремих об'єктів. Напрямок стрілки вказує на одержувача повідомлення. На діаграмах кооперації може використовуватися один з чотирьох типів стрілок для позначення повідомлень:
А) позначає виклик процедури або іншого вкладеного потоку управління. Зазвичай всі такі повідомлення є синхронними, т. Е. Ініційованими по завершенні певної діяльності або при виконанні деякої умови.
Б) позначає простий потік управління. Кожна така стрілка зображує один етап в послідовності потоку керування. Зазвичай всі такі повідомлення є асинхронними.
В) використовується для позначення асинхронного потоку управління. Відповідні повідомлення формуються в довільні, заздалегідь не відомі моменти часу, як правило, активними об'єктами. Зазвичай повідомлення цього типу є початковими і звичайно ініціюються акторами.
Г) позначає повернення з виклику процедури. Стрілки цього типу часто відсутні на діаграмах кооперації, оскільки неявно передбачається їх існування після закінчення процесу активізації деякої діяльності.
Система електронних платежів (СЕП-2) та її роль у банківській системі України.
Система електронних платежів побудована як деревоподібна мережна структура.
На нижньому рівні СЕП розташовані банки - учасники електронних розрахунків. Середній рівень представлений мережею регіональних розрахункових палат (РРП) - це підрозділ регіонального управління НБУ, який обслуговує банки - учасники СЕП відповідного регіону. На верхньому рівні розміщена Центральна розрахункова палата (ЦРП), яка організовує функціонування СЕП у цілому та керує роботою регіональних розрахункових палат.
Система електронних платежів складається з:
- прикладного програмного забезпечення - набору комп'ютерних програм, що дозволяють системі вирішувати конкретні задачі, які ставляться користувачами;
- телекомунікаційного середовища, що включає апаратуру зв'язку та системне програмне забезпечення, що служать для обміну інформацією про платежі та іншими контрольними повідомленнями між відправником,, обробником та отримувачем інформації;
- засобів захисту інформації (програмно-технічних, нормативно-правових, адміністративно-організаційних).
У свою чергу прикладне програмне забезпечення складається з програмно-технічних комплексів автоматизованих робочих місць (АРМ) СЕП призначених для проведення розрахунків; системи резервування роботи СЕП у разі збоїв, відмов обладнання або інших надзвичайних ситуацій; інформаційно-пошукової системи, призначеної для одержання довідкової інформації про проходження платежів.
Електронні платіжні документи, що приймаються у СЕП, готуються в програмному комплексі "операційний день банку" (ОДБ). ОДБ має забезпечувати коректне формування і захист електронних розрахункових документів та службових повідомлень СЕП відповідно до вимог НБУ.
Компоненти системи (програмне забезпечення АРМ НБУ СЕП, програмні та апаратні засоби захисту, програмні засоби електронної пошти НБУ) надаються учасникам СЕП відповідними Регіональними розрахунковими палатами. Регіональні розрахункові палата та Центральна розрахункова палата отримують їх від структурних підрозділів НБУ, у функції яких входить розробка і впровадження нових версій компонентів системи.
Структура «Технічного завдання».
Згідно з чинними стандартами ТЗ повинно включати в себе такі відомості про об'єкт розробки:
1. Найменування об'єкта розробки, та область застосування.
повне найменування об'єкта та його умовне позначення,
шифр теми або шифр (номер) договору,
перелік документів, на підставі яких створюється проект, ким і коли затверджені ці документи,
планові терміни початку та закінчення робіт із створення об'єкта.
2. Підстава для розробки та назва проектної організації:
найменування підприємств розробника і замовника системи та їхні реквізити;
перелік юридичних та фінансових документів, на підставі яких створюється система, ким і коли затверджені ці документи;
відомості про джерела та порядок фінансування робіт.
3. Мета розробки.
4. Джерела розробки. Тут повинні бути перераховані документи та інформаційні матеріали (техніко-економічне обґрунтування, звіти про закінчені науково-дослідні роботи, інформаційні посилання на вітчизняні і зарубіжні аналоги та ін.), на підставі яких розроблялося ТЗ і які мають бути використані при створенні системи.
5. Технічні вимоги, які включають:
склад об'єкта та вимоги до його конструктивного виконання;
показники призначення та економічного використання сировини, матеріалів, палива і енергії;
вимоги до надійності;
вимоги до технологічності;
вимоги до рівня уніфікації і стандартизації;
вимоги безпеки при роботі обладнання;
естетичні і ергономічні вимоги;
вимоги до складових частин продукції, сировини і експлуатаційних матеріалів;
вимоги патентної чистоти;
вимоги експлуатації, вимоги до технічного обслуговування і ремонту;
вимоги до категорії якості.
6. Економічні показники:
гранична ціна;
економічний ефект;
термін окупності витрат на розробку і освоєння об'єкта;
допустима річна потреба в об'єкті проектування.
7. Порядок контролю і приймання об'єкта:
види, склад, обсяг і методи випробувань системи та її складових частин (види випробувань відповідно до чинних норм, які поширюються на систему, що розробляється);
загальні вимоги до приймання робіт (продукції) за стадіями (перелік учасників, місце і терміни проведення), порядок узгодження і затвердження приймальної документації;
статус приймальної комісії.
Метод IDEF3.
IDEF3 - методологія моделювання і стандарт документування процесів, що відбуваються в системі. Метод документування технологічних процесів являє собою механізм документування та збору інформації про процеси. IDEF3 показує причинно-наслідкові зв'язки між ситуаціями і подіями в зрозумілому для експерта формі, використовуючи структурний метод вираження знань про те, як функціонує система, процес або підприємство.
IDEF3 широко застосовується при розробці інформаційних систем. При цьому використовується інструмент візуального моделювання бізнес-процесів.
Два типи діаграм в IDEF3:
Система описується як упорядкована послідовність подій з одночасним описом об'єктів, що має відношення до процесу моделювання.
IDEF3 складається з двох методів. Process Flow Description (PFD) - Опис технологічних процесів, із зазначенням того, що відбувається на кожному етапі технологічного процесу. Object State Transition Description (OSTD) - опис переходів станів об'єктів, із зазначенням того, які існують проміжні стани у об'єктів в моделюється системі.
Основу методології IDEF3 становить графічна мова опису процесів. Модель в нотації IDEF3 може містити два типи діаграм:
діаграма Опис Послідовності Етапів Процесу (Process Flow Опис діаграма, PFDD)
діаграма Мережі Трансформацій Станів Об'єкта (Object перехід стан мережу, OSTN)
Використання UML .
Більшість сучас методів ООАП базуються на викор мови UML. Уніфікована мова модел-ня UML (Unified Modeling Language) є мовою для виз-нач, подання, проект-ня і документування програмних систем, організаційно-екон сис-тем, тех систем та ін систем різної природи. UML містить стандартний набір діаграм і нотацій найрізноманітніших видів. UML-це наступник того покоління методів ООАП, які з'явилися в кінці 1980-х і на поч 1990-х рр. Створення UML фактично розпочалося в кінці 1994 p., коли Граді Вуч і Джеймс Рамбо почали роботу щодо об'єднання їх методів Booch і ОМТ (Object Modeling Technique) під егідою компанії Rational Software. До кінця 1995р. вони створили першу специфікацію об'єднаного методу, названого ними Unified Method. Тоді ж у 1995 р. до них приєднався автор методу OOSE (Object-Oriented Software Engineering) І. Якобсон. Таким чином, UML є прямим об'єднанням і уніфікацією методів Г. Буча, Д. Рам-бо і Г. Якобсона, проте доповнює їх новими можливостями. Головними при розробці UML були такі цілі: надати користувачам готову до викор виразну мову візуального модел-ня, що дозволяє їм розробляти осмис-лені моделі й обмінюватися ними; передб механізми розширюваності і спеціалізації для розширення базових концепцій; забезпеч незалежність від конкретних мов програмування і процесів розробки; забезпеч форма-льну основу для розуміння цієї мови модел-ня (мова має бути одночасно точною і доступною для розуміння, без зайвого формалізму); стимулюва-ти зростання ринку об'єктно-орієнтованих інструментальних засобів; інтегрувати кращий практичний досвід. UML прийнятий на озброєння практично всіма найбільшими компаніями - виробниками ПЗ (Microsoft, Oracle, IBM, Hewlett-Packard, Sybase тощо). Крім того, практично всі світові виробники CASE-засобів, крім IBM Rational Software, підтримують UML у своїх продуктах (Oracle Designer, Together Control Center (Borla-nd), AllFusion Component Modeler (Computer Associates), Microsoft Visual Modeler). Стандарт UML версії 1.1, прий-нятий OMG у 1997 p., містить такий набір діаграм: Структурні моделі (structural): діаграми класів (class diagrams) - для моделювання статичної структури класів системи і зв'язків між ними; діаграми компонентів (com-ponent diagrams)-для моделювання ієрархії компонентів (підсистем) сис-теми; послідовність виконуваних дій; передачу інфи між функціональни-ми процесами; відношення між даними. Поширеними моделями проект-ня ПЗ: 1) функціональна модель SADT (Structured Analysis and Design Technique); 2) модель IDEF3; 3) DFD (Data Flow Diagrams) - діаграми потоків даних.