ORM

2025-09-03 02:26
bga68comp: (Default)

ORM (Object-Relational Mapping / Об’єктно-реляційне відображення) — це програмна технологія, яка дозволяє працювати з базою даних не напряму через SQL-запити, а через об’єкти мови програмування.

Простими словами:

  • Без ORM: ви пишете SELECT * FROM users WHERE id=1;
  • З ORM: ви пишете User.find(1) і отримуєте об’єкт User, з яким можна працювати у коді.

Де застосовується

  • ORM є проміжним шаром (layer) між додатком і БД.
  • Він транслює методи й властивості об’єктів у SQL-запити і назад.
  • Це робить код простішим, зручнішим у підтримці та менш залежним від конкретної СУБД.

Приклади ORM

  • Java: Hibernate, EclipseLink
  • .NET: Entity Framework
  • Python: SQLAlchemy, Django ORM
  • Ruby: ActiveRecord
  • PHP: Doctrine, Eloquent (Laravel)


Tags:
  • Add Memory
  • Share This Entry

ISO/IEC/IEEE 42010: Viewpoint & View

2025-09-03 02:09
bga68comp: (Default)

У ISO/IEC/IEEE 42010 (Systems and Software Engineering — Architecture Description) є два близькі, але різні поняття:

Viewpoint (точка зору)

  • Визначення: це "шаблон" або правило, яке пояснює як і для кого треба створювати архітектурне подання.
  • Він відповідає на питання: які інтереси стейкхолдера ми показуємо, яку інформацію включаємо, якими засобами (діаграми, таблиці, текст) описуємо.
  • Простими словами: viewpoint — це інструкція або рецепт для створення подання.

View (подання)

  • Визначення: це конкретний результат застосування viewpoint до вашої системи.
  • Тобто це вже готова діаграма, таблиця чи текст, що показує систему під певним кутом зору.
  • Простими словами: view — це фото системи, зроблене за тим рецептом.

Приклад

Уявімо, що будуємо архітектуру для хмарної платформи:
  1. Stakeholder (зацікавлена сторона)
    • CIO (Chief Information Officer, директор з ІТ)
    • Його concern (потреба): чи масштабована система і як забезпечено інтеграцію між додатками?
  2. Viewpoint (точка зору на інтеграцію додатків)
    • Назва: Application Communication Viewpoint
    • Призначення: показати, як взаємодіють модулі та сервіси
    • Мова: UML Component Diagram або ArchiMate Application Collaboration
    • Яку інформацію включати: сервіси, API, протоколи, залежності
  3. View (конкретне подання)
    • Діаграма з Azure AD, веб-додатком на Ubuntu, RDS MySQL, інтеграцією з O365.
    • Тут видно, що користувачі логіняться через Entra ID, доступ йде через API-шлюз, БД інтегрується через ORM-шар.
    • Це вже готова картинка, яку CIO може подивитися.

🔹 Отже:
  • Viewpoint = каже: "покажи архітектуру додатків через компоненти і протоколи"
  • View = конкретна діаграма з вашим Entra ID, API Gateway і MySQL


Tags:
  • Add Memory
  • Share This Entry

TOGAF vs ISO 42010 vs Разом

2025-09-03 01:51
bga68comp: (Default)

В чому незручність, коли використовують тільки одну методологію для опису архітектурних рівнів?

  • TOGAF дає методологію (ADM-фази, артефакти, каталоги, матриці), але іноді в ньому бракує гнучкості у формальному представленні результатів.
  • ISO/IEC/IEEE 42010 дає рамку опису архітектури: хто стейкхолдери, які їхні потреби (concerns), через які viewpoints ці потреби відображати, і у вигляді яких views це презентувати.
  • Якщо користуватися лише TOGAF — є ризик, що опис буде “каталог + текст”, але не зовсім зрозумілий різним групам зацікавлених сторін.
  • Якщо користуватися лише ISO 42010 — буде гарна структура “хто/що/для чого”, але без готових методичних кроків і артефактів (каталогів, матриць).

Комбінація TOGAF і ISO/IEC/IEEE 42010 методично сильніша, ніж використання кожного окремо: TOGAF забезпечує процес і набір артефактів, а ISO 42010 — формалізований спосіб представлення архітектури через стейкхолдерів, concerns і viewpoints. Разом вони дозволяють зробити опис не лише повним, а й зрозумілим для різних аудиторій.

Критерій TOGAF ISO/IEC/IEEE 42010 Разом (TOGAF + ISO 42010)
Призначення Методологія розробки архітектури (ADM, фази, артефакти) Рамка для опису архітектури (stakeholders, concerns, viewpoints, views) Повний цикл: розробка + формалізований опис
Сильна сторона Дає покроковий процес (ADM) і набір артефактів (каталоги, матриці) Дає чітку структуру для комунікації з різними стейкхолдерами Виходить і методика роботи, і методика подачі результатів
Слабка сторона Може вийти занадто “всередину ІТ”, важко донести до нефахівців Немає власної методики створення артефактів, лише правила їх опису Компенсують слабкі сторони один одного
Фокус Що і як робити (Data, Application, Technology, Business Architectures) Як показати і пояснити (concerns, viewpoints, views) І процес, і представлення зрозумілі й прозорі
Приклад результату Каталоги даних, матриці застосунків, моделі потоків Logical Data View, Security View, паспорти viewpoints Каталоги + матриці (TOGAF), оформлені у views для різних стейкхолдерів (ISO 42010)


Таким чином, можна сказати так — разом вони дають повну картину:
  • TOGAF = як і що робити (ADM, каталоги, матриці).
  • ISO 42010 = як правильно це описати й донести (stakeholders, concerns, viewpoints, views).

Див. також:
⋄ Приклад опису архітектури системи згідно TOGAF → https://bga68comp.dreamwidth.org/787432.html


Tags:
  • Add Memory
  • Share This Entry

Інформаційна архітектура ІТ-системи компанії. Приклад

2025-06-26 20:58
bga68comp: (Default)

Продовжуємо розбирати шаблони рівнів архітектури ІТ-систем. Це доповнення до опису архітектури за посиланнями:
• Приклад опису архітектури системи згідно TOGAF
• Побудова віртуальної інфраструктури на базі Microsoft Azure



✅ Опис інформаційної архітектури компанії
🖼️ Згідно з наданою схемою (RDS, Files, IIS Web Front/Back, AD DC1/DC2, VPN)

🧾 Інформаційна архітектура ІТ-системи компанії

🔹 1. Методологія

  • TOGAF 9.2, ADM, фаза C (Data Architecture): побудова інформаційного рівня архітектури.
  • ISO/IEC/IEEE 42010:2011: опис архітектури через зацікавлені сторони, погляди (views), моделі та відповідності.

🔹 2. Архітектурний контекст

  • Усі серверні ресурси компанії розміщені в тенанті Azure.
  • Користувачі підключаються до корпоративної мережі через захищені канали (VPN або Azure Bastion).
  • Робоче середовище реалізоване через RDS-сервер (DevSRV).
  • Веб-додатки розділені на фронт- (IIS Web Front) та бекенд (IIS Web Back).
  • Ідентифікація та авторизація забезпечуються двома доменними контролерами (AD DC1, DC2).

🔹 3. Архітектурні погляди (Views)

3.1 📡 Deployment View

  • DevSRV – RDS сервер для користувачів.
  • Files – файловий сервер зі спільними каталогами.
  • IIS Web Srv Front / Back – розподілення логіки веб-додатку.
  • AD DC1 / DC2 – розподілена автентифікація, DNS, GPO.
  • Всі ресурси ізольовані через NSG, Firewall, розміщені у VNet з Subnet-сегментацією.
  • Користувачі підключаються через захищений шлюз (VPN/Bastion).

3.2 🧩 Data Architecture View

Сутність даних Опис
User Profile Профілі користувачів, зберігаються в AD та RDS
File Object Файли користувача на файловому сервері
DNS-записи Зони та записи, керуються AD DC1/DC2
Web Session Дані сесій на IIS Front
GPO Configuration Групові політики, що застосовуються через AD
RDP Logs Логи входів і дій у RDS

3.3 🔐 Access & Security View

  • RBAC на основі груп у AD.
  • GPO-політики: заборона USB, блокування локального диска, перенаправлення папок.
  • Шифрування: RDP over TLS, SMB over TLS.
  • Аудит: централізоване логування входів, дій на RDS.
  • Двофакторна автентифікація (MFA) через Azure AD / Conditional Access.
  • Firewall + NSG: розмежування Frontend, Backend, Infra.

3.4 🔄 Information Flow View

Звідки → Куди Протокол Захист
Користувач → RDS RDP over TLS VPN / MFA / GPO
RDS → Files SMB 3.0 ACL + GPO + TLS
RDS → AD LDAP/Kerberos Шифрування, автентифікація
RDS → IIS Front/Back HTTP/HTTPS ACL, WAF, сегментація
RDS → DNS DNS ACL-захист зони

🔹 4. Зацікавлені сторони (Stakeholders)

Сторона Інтерес
Користувачі Стабільний і безпечний доступ до робочого середовища
Системні адміністратори Централізоване управління політиками та файлами
Відділ ІБ Впровадження GPO, аудит, захист інформації
Бізнес Доступність сервісів, віддалена робота

🔹 5. Цільова модель та вдосконалення

Компонент Поточна реалізація Рекомендоване покращення
RDS DevSRV на VM Перехід до RDS Farm + Load Balancer
Files Windows FS Azure Files + Private Endpoint
MFA Часткове Універсальне MFA через Azure AD
AD DC1 + DC2 Гібрид із Azure AD DS
IIS Front/Back На VM Azure App Service або контейнеризація

🔹 6. Узгодженість із ISO/IEC/IEEE 42010

Компонент Відповідність
Stakeholders Визначено
Architectural Views Згруповано (Deployment, Security, Data)
Вимоги Ураховані: доступність, безпека, контроль
Traceability Показано зв’язок між цілями й рішеннями

✅ На останок:

Інформаційна архітектура побудована згідно з TOGAF ADM (фаза C) та структурована за стандартом ISO 42010.
Враховано як функціональні, так і нефункціональні вимоги: доступність, безпека, масштабованість.
Усі основні компоненти (RDS, Files, AD, IIS) інтегровані через захищені канали й управляються централізовано.


Annex:
🟠 Фази ADM (Architecture Development Method)

  1. Preliminary Phase
  2. Phase A: Architecture Vision
  3. Phase B: Business Architecture
  4. Phase C: Information Systems Architectures
  5. Phase D: Technology Architecture
  6. Phase E: Opportunities and Solutions
  7. Phase F: Migration Planning
  8. Phase G: Implementation Governance
  9. Phase H: Architecture Change Management
  10. Requirements Management


Tags:
  • Add Memory
  • Share This Entry

Windows Server. Как узнать кем из пользователей была создана эта папка?

2015-12-07 15:02
bga68comp: (Default)
Windows Server. Как узнать кем из пользователей была создана эта папка?

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

Как узнать кем из пользователей были созданы эти "непонятные" папки?

Открываем Свойства папки → Безопасность → Дополнительно → Владелец и видим того, кто создал эту папку:



 
 
Tags:
  • Add Memory
  • Share This Entry

Profile

bga68comp: (Default)
bga68comp

December 2025

S M T W T F S
  12 3 456
7891011 1213
14151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated 2025-12-31 22:13
Powered by Dreamwidth Studios