UML 다이어그램 종류 완벽히 이해해보자

클래스, 시퀀스, 유스케이스 등 주요 UML 다이어그램 종류를 실무 예제와 함께 알아보세요. 소프트웨어 설계 능력을 한 단계 업그레이드하세요.

소프트웨어 개발에서 복잡한 시스템을 설계할 때, 팀원들과 명확하게 소통하는 것은 필수입니다. 코드로 바로 구현하기 전에 시스템의 구조와 동작 방식을 시각화할 수 있다면 어떨까요? 바로 이 지점에서 UML(Unified Modeling Language)이 그 역할을 수행합니다.

UML은 객체 지향 소프트웨어 시스템을 시각화, 명세화, 구축, 문서화하기 위한 표준 모델링 언어입니다. 1990년대 중반에 등장한 이후, UML은 소프트웨어 엔지니어링의 핵심 도구로 자리 잡았습니다. 특히 마이크로서비스 아키텍처나 대규모 시스템 설계가 일상화된 지금, UML의 중요성은 더욱 커지고 있어요.

UML은 크게 구조적 다이어그램(Structural Diagrams)과 행위적 다이어그램(Behavioral Diagrams)으로 나뉩니다. 각 다이어그램은 시스템의 특정 측면을 표현하는 데 최적화되어 있죠. 이 글에서는 실무에서 자주 사용되는 UML 다이어그램 종류를 상세히 살펴보고, 각 다이어그램이 어떤 상황에서 유용한지 실제 예시와 함께 알아보겠습니다.

관계 (Relationships)

클래스 다이어그램의 진정한 힘은 클래스 간의 관계를 명확히 보여주는 데 있습니다. 관계는 주로 화살표로 표현되며, 각기 다른 모양의 화살표는 서로 다른 의미를 가집니다. 화살표 방향은 한 클래스가 다른 클래스를 어떻게 사용하는지를 나타냅니다.

관계 유형	의미	화살표/기호 형태	설명
일반화 (Generalization)	상속 관계		부모 클래스(Superclass)와 자식 클래스(Subclass) 간의 관계를 나타냅니다.
실체화 (Realization)	인터페이스 구현 관계		클래스가 인터페이스를 implements할 때 사용합니다. 점선 화살표로 표현합니다.
연관 (Association)	참조 관계		한 클래스가 다른 클래스의 객체를 속성으로 참조합니다. 방향성은 참조 흐름을 나타냅니다.
의존 (Dependency)	일시적 사용 관계		한 클래스가 다른 클래스를 메서드 매개변수나 반환 값으로 사용하는 관계입니다.
집합 (Aggregation)	약한 전체-부분 관계		‘전체’가 ‘부분’을 포함하지만, 부분의 생명주기가 전체에 의존하지 않습니다.
합성 (Composition)	강한 전체-부분 관계		부분의 생명주기가 전체에 완전히 종속될 때 사용합니다.

구조적 다이어그램 (Structural Diagrams)

구조적 다이어그램은 시스템의 정적 구조를 표현합니다. 즉, 시스템을 구성하는 요소들과 그들 간의 관계를 보여주는 것이죠.

클래스 다이어그램 (Class Diagram)

클래스 다이어그램(Class Diagram)은 객체 지향 설계(OOD, Object-Oriented Design)에서 가장 핵심이 되는 UML 다이어그램입니다.

클래스 다이어그램 자세히 알아보기

시스템을 구성하는 클래스, 그들의 속성(Attributes)과 메서드(Methods), 그리고 클래스 간의 관계(Relationships)를 시각적으로 표현하죠.

즉, 시스템의 정적 구조(static structure)를 한눈에 보여주는 설계의 청사진(blueprint) 역할을 합니다.

특히 복잡한 도메인 모델을 설계할 때, 비즈니스 로직의 핵심 개념을 팀 전체가 공유할 수 있도록 도와줍니다.

주요 구성 요소:

• 클래스(Class): 속성(attributes)과 메서드(methods)를 포함
• 속성(Attributes): 클래스가 가지는 데이터
• 메서드(Methods): 클래스가 수행하는 기능
• 관계(Relationships): 상속, 연관, 집합, 의존 등

실무 활용 예시:

쇼핑몰 시스템을 개발한다고 가정해볼게요. ‘사용자(User)’, ‘상품(Product)’, ‘주문(Order)’ 클래스와 이들의 상호작용을 클래스 다이어그램으로 표현할 수 있습니다.

classDiagram
    class User {
        - userId: int
        - name: string
        - email: string
        + login(): void
        + logout(): void
    }

    class Product {
        - productId: int
        - name: string
        - price: float
        + getInfo(): string
    }

    class Order {
        - orderId: int
        - date: Date
        - total: float
        + calculateTotal(): float
    }

    User "1" --> "1..*" Order : places >
    Order "1..*" --> "1..*" Product : contains >

클래스 다이어그램은 시스템의 청사진 역할을 하며, 개발 초기 단계에서 팀원들과 구조를 공유하는 데 매우 효과적입니다.

객체 다이어그램 (Object Diagram)

객체 다이어그램(Object Diagram)은 클래스 다이어그램의 인스턴스 버전(instance-level diagram)이라고 볼 수 있습니다. 즉, 특정 시점에서 시스템에 존재하는 객체(instance)와 그 객체들 간의 관계, 그리고 실제 데이터 값을 구체적으로 보여주는 다이어그램이에요.

객체 다이어그램 자세히 알아보기

시스템의 구조를 설계하는 것이 클래스 다이어그램이라면, 객체 다이어그램은 시스템의 현재 상태(snapshot)를 시각화하는 도구입니다.

클래스 다이어그램과의 차이점:

• 클래스 다이어그램: 추상적인 클래스와 관계 모델
• 객체 다이어그램: 특정 시점의 구체적인 인스턴스

실무 활용 예시:

로그인 프로세스에서 '사용자 객체(user object)'가 '인증 객체(authentication object)'와 어떻게 상호작용하는지 시각화할 때 유용합니다. 예를 들어, 사용자 "김철수"가 로그인을 시도하는 순간의 객체 상태를 표현할 수 있죠.

classDiagram
    class User {
        userId = 101
        name = "김철수"
        email = "kim@example.com"
    }

    class Authentication {
        sessionId = "abc123"
        isValid = true
    }

    User "1" --> "1" Authentication : authenticates >

객체 다이어그램은 시스템의 런타임 상황을 이해하는 데 특히 도움이 됩니다.

컴포넌트 다이어그램 (Component Diagram)

컴포넌트 다이어그램(Component Diagram)은

시스템을 구성하는 물리적/논리적 컴포넌트 간의 관계와 의존성을 시각화하는 UML 구조 다이어그램입니다.

즉, “이 시스템이 어떤 모듈들로 구성되어 있으며, 각 모듈이 어떻게 연결되어 협력하는가”를 보여주는 소프트웨어 구조의 지도(Map) 역할을 합니다. 특히 대규모 애플리케이션이나 마이크로서비스 아키텍처(MSA) 환경에서 시스템의 모듈화(Modularity), 의존성 관리(Dependency Management), 재사용성(Reusability)을 설계할 때 핵심적으로 사용됩니다.

주요 구성 요소:

• 컴포넌트(Components): 논리적 또는 물리적 컴포넌트 (예: 비즈니스 컴포넌트, EJB 컴포넌트)
• 인터페이스(Interfaces): 제공(provided)되거나 요구(required)되는 인터페이스
• 의존성(Dependencies): 컴포넌트 간의 관계

실무 활용 예시:

마이크로서비스 기반 전자상거래 시스템에서:

• 사용자 서비스 컴포넌트
• 주문 서비스 컴포넌트
• 결제 서비스 컴포넌트
• 재고 관리 컴포넌트

이들이 어떻게 연결되고 통신하는지를 컴포넌트 다이어그램으로 명확히 표현할 수 있습니다.

graph TD
    subgraph Frontend Layer
        A[🧑‍💻 Web Client]
    end

    subgraph Backend Services
        B[User Service]
        C[Order Service]
        D[Payment Service]
        E[Inventory Service]
    end

    A -->|REST API| B
    A -->|REST API| C
    C -->|calls| D
    C -->|fetches| E
    D -->|notifies| C

이 다이어그램은 클라이언트가 여러 백엔드 서비스를 호출하고, 서비스 간 의존 관계가 Order → Payment → Inventory 방향으로 이어지는 구조를 표현합니다.

classDiagram
    class UserService {
        +registerUser()
        +login()
        +getProfile()
    }

    class OrderService {
        +createOrder()
        +getOrderHistory()
        -verifyPayment()
    }

    class PaymentService {
        +processPayment()
        +refund()
    }

    class InventoryService {
        +checkStock()
        +updateStock()
    }

    UserService --> OrderService : uses >
    OrderService --> PaymentService : depends on >
    OrderService --> InventoryService : requests >

위 예시에서는 OrderService가 PaymentService와 InventoryService의 기능을 사용하며, UserService는 독립적으로 사용자 관련 기능을 제공합니다.

컴포넌트 다이어그램을 통해 시스템의 모듈화와 재사용 가능성을 높일 수 있어요.

배포 다이어그램 (Deployment Diagram)

배포 다이어그램(Deployment Diagram)은 소프트웨어 시스템의 물리적 배포 구조(Physical Deployment Structure)를 시각화하는 다이어그램이에요.

즉, 어떤 하드웨어 노드(Node) 위에 어떤 소프트웨어 컴포넌트(Artifact)가 배포되는지를 표현합니다. 이 다이어그램은 개발 단계에서 시스템을 논리적으로 설계한 후, 운영 환경(Production Environment)에 실제로 어떻게 배포될지를 정의할 때 필수적이에요.

특히 클라우드, 온프레미스, 하이브리드 인프라 등 다양한 환경에서 인프라 구조를 문서화하고 팀 간 공유하는 핵심 자료로 사용됩니다.

주요 구성 요소:

• 노드(Nodes): 하드웨어 장치 (예: 서버, 데이터베이스)
• 아티팩트(Artifacts): 소프트웨어 컴포넌트 (예: 실행 파일, 라이브러리)
• 통신 경로(Communication Paths): 노드 간의 연결

실무 활용 예시:

클라우드 기반 서비스의 인프라를 설계할 때 배포 다이어그램이 매우 유용합니다. AWS 환경에서의 배포 구조를 예로 들면:

graph TD
    subgraph AWS Cloud
        LB[Load Balancer 🌀]
        subgraph EC2 Cluster
            WS1[Web Server 1 🖥️]
            WS2[Web Server 2 🖥️]
        end
        DB[(RDS Database 🗄️)]
    end

    LB --> WS1
    LB --> WS2
    WS1 --> DB
    WS2 --> DB

이를 통해 시스템 배포 시 필요한 리소스와 구성을 한눈에 파악할 수 있습니다.

패키지 다이어그램 (Package Diagram)

패키지 다이어그램(Package Diagram)은 대규모 소프트웨어 시스템의 구조를 계층적(Hierarchical)으로 표현하는 UML 구조 다이어그램입니다.

즉, 복잡한 시스템을 의미 있는 그룹(패키지) 으로 묶어 관리함으로써 모듈 간 의존성(Dependency) 과 계층 구조(Layered Architecture) 를 명확하게 보여줍니다.

개발팀에서는 이 다이어그램을 통해 프로젝트 구조를 문서화하고, 코드 의존 관계를 분석하며, 계층 간의 역할을 명확히 구분할 수 있습니다.

주요 구성 요소:

• 패키지(Packages): 관련 요소들의 그룹
• 의존성(Dependencies): 패키지 간의 관계

실무 활용 예시:

대형 엔터프라이즈 애플리케이션에서 레이어별로 패키지를 구성할 때:

graph TD
    A[Presentation Layer] --> B[Business Layer]
    B --> C[Data Access Layer]
    C --> D[Database Package]

패키지 다이어그램을 사용하면 큰 프로젝트를 관리 가능한 단위로 나누고, 각 모듈 간의 의존성을 명확히 할 수 있습니다.

복합 구조 다이어그램 (Composite Structure Diagram)

복합 구조 다이어그램(Composite Structure Diagram)은 클래스(Class)나 컴포넌트(Component)의 내부 구조와 런타임 협력 관계를 세밀하게 시각화하는 UML 구조 다이어그램입니다.

즉, “한 클래스의 내부가 실제로 어떤 객체들로 구성되어 있고, 이들이 어떤 방식으로 협력하며 동작하는가”를 보여주는 다이어그램이에요. 시스템의 전체 구조가 아니라, 부분(Part) 단위의 내부 구성을 이해할 때 유용합니다.

주요 용도:

• 분류자의 내부 구조 표현
• 포트를 통한 분류자와 환경 간의 상호작용
• 협력 동작 표현

실무 활용 예시:

복잡한 게임 엔진의 각 컴포넌트가 어떻게 상호작용하는지 이해할 때 유용합니다. 예를 들어, 렌더링 엔진, 물리 엔진, 오디오 시스템이 게임 루프 내에서 어떻게 협력하는지를 표현할 수 있죠.

flowchart TD
    subgraph GameEngine[🎮 Game Engine]
        R[Render Engine]
        P[Physics Engine]
        A[Audio System]
        L[Game Loop]
        R --> L
        P --> L
        A --> L
    end

복합 구조 다이어그램은 클래스의 전체가 아닌 개별 클래스를 부분적으로 표현하여, 시스템의 세부 동작을 이해하는 데 도움을 줍니다.

행위적 다이어그램 (Behavioral Diagrams)

행위적 다이어그램은 시스템의 동적 동작을 표현합니다. 시스템이 어떻게 작동하고, 객체들이 어떻게 상호작용하는지를 보여주죠.

유스케이스 다이어그램 (Use Case Diagram)

유스케이스 다이어그램(Use Case Diagram)은 사용자(Actor)의 관점에서 시스템이 제공해야 할 기능적 요구사항(Functional Requirements)을 시각화하는 UML 다이어그램이에요.

즉, “누가 시스템을 사용하며, 어떤 기능을 통해 목표를 달성하는가”를 보여주는 요구사항 분석의 출발점이자 비즈니스 흐름 설계의 기초입니다.

주요 구성 요소:

• 액터(Actors): 시스템과 상호작용하는 사용자나 외부 시스템
• 유스케이스(Use Cases): 측정 가능한 비즈니스 가치를 제공하는 고수준 비즈니스 목표

실무 활용 예시:

온라인 쇼핑몰 시스템의 유스케이스:

graph TD
    A[Customer] --> B((Browse Products))
    A --> C((Add to Cart))
    A --> D((Checkout))
    D --> E((Login))
    D --> F((Payment))
    F --> G((Send Confirmation Email))

각 유스케이스는 시스템이 제공해야 하는 기능을 나타내며, 요구사항 수집 단계에서 매우 유용합니다.

활동 다이어그램 (Activity Diagram)

활동 다이어그램(Activity Diagram)은 시스템 내의 비즈니스 프로세스나 알고리즘의 흐름(Flow of Control)을 단계별로 시각화하는 UML 행위(Behavioral) 다이어그램입니다.

즉, 시스템이 “무엇을 어떤 순서로 수행하는가”를 표현하는 다이어그램이에요.

선택(Decision), 병렬(Parallel), 반복(Loop) 등의 제어 구조를 모두 표현할 수 있기 때문에 복잡한 업무 흐름이나 사용자 시나리오를 명확하게 시각화할 수 있습니다.

주요 구성 요소:

• 활동(Activities): 수행되는 작업
• 결정(Decisions): 조건부 분기
• 흐름(Flows): 활동 간의 전환

실무 활용 예시:

회원가입부터 이메일 인증까지의 프로세스를 표현할 때:

flowchart TD
    A([시작]) --> B[회원 정보 입력]
    B --> C{이메일 형식 유효한가?}
    C -->|유효| D[DB 저장]
    C -->|무효| E[오류 메시지 표시]
    D --> F[인증 메일 발송]
    F --> G[사용자 이메일 확인 대기]
    G --> H{인증 성공?}
    H -->|성공| I[계정 활성화]
    H -->|실패| J[재시도 요청]
    I --> K([종료])
    J --> G

활동 다이어그램은 비즈니스 프로세스를 문서화하고, 개발팀과 비즈니스 팀 간의 커뮤니케이션을 원활하게 합니다.

상태 머신 다이어그램 (State Machine Diagram)

상태 머신 다이어그램(State Machine Diagram)은 객체(Object)나 시스템(System)의 상태 변화(State Changes)를 시간의 흐름에 따라 시각화한 다이어그램이에요.

특정 객체가 “어떤 사건(Event)”에 의해 어떤 상태(State)로 전이(Transition)되는지를 보여주기 때문에, 시스템의 라이프사이클(Lifecycle)을 분석하고 예측하는 데 매우 유용합니다.

주요 구성 요소:

• 상태(States): 객체가 가질 수 있는 조건
• 전이(Transitions): 한 상태에서 다른 상태로의 변화
• 이벤트(Events): 전이를 유발하는 트리거

실무 활용 예시:

온라인 주문 시스템에서 주문 상태의 변화를 표현할 때:

stateDiagram-v2
    [*] --> 대기
    대기 --> 처리중 : 주문 접수
    처리중 --> 배송중 : 출고
    배송중 --> 완료 : 배송 완료
    대기 --> 취소됨 : 취소
    처리중 --> 취소됨 : 취소
    완료 --> [*]
    취소됨 --> [*]

상태 머신 다이어그램을 통해 객체의 가능한 상태와 전이를 명확히 정의하여, 시스템의 동작을 예측 가능하게 만들 수 있습니다.

시퀀스 다이어그램 (Sequence Diagram)

시퀀스 다이어그램(Sequence Diagram)은 시간의 흐름에 따라 객체 간의 메시지 교환 과정을 표현하는 UML 상호작용(Interaction) 다이어그램입니다.

즉, 특정 시나리오(예: 로그인, 주문 처리, 결제 등)에서 “누가 언제 누구에게 어떤 메시지를 보냈는가”를 시간 순서대로 시각화하는 다이어그램이에요.

소프트웨어의 동적 행위(Behavioral Aspect)를 명확하게 보여주며, API 호출 구조나 서비스 간 통신 흐름을 설계할 때 매우 유용합니다.

주요 구성 요소:

• 객체(Objects): 상호작용에 참여하는 인스턴스
• 메시지 시퀀스(Message Sequences): 시간 순서에 따른 메시지 전달

실무 활용 예시:

사용자 로그인 프로세스를 시퀀스 다이어그램으로 표현하면:

sequenceDiagram
    participant User as 🧑 User
    participant UI as 💻 Web UI
    participant Auth as 🔐 AuthService
    participant DB as 🗄️ Database

    User->>UI: 로그인 클릭
    UI->>Auth: 자격 증명(이메일, 비밀번호) 전송
    Auth->>DB: 사용자 조회 쿼리 실행
    DB-->>Auth: 사용자 정보 반환
    Auth-->>UI: 인증 결과 (성공/실패)
    UI-->>User: 로그인 결과 표시

시퀀스 다이어그램은 API 설계, 디버깅, 시스템 통합 시 매우 유용합니다. 특히 분산 시스템에서 여러 서비스 간의 통신 흐름을 이해하는 데 효과적이에요.

상호작용 다이어그램 (Interaction Diagram)

상호작용 다이어그램(Interaction Diagram)은 객체 간의 메시지 교환과 이벤트 흐름을 시간 순서대로 표현하는 UML 다이어그램입니다.

즉, “어떤 객체가 언제, 누구에게 무엇을 요청하고, 어떤 응답을 받는가”를 명확히 보여줍니다. 이를 통해 시스템의 동적 행위(Behavior)를 이해하고, 실제 실행 흐름을 시각적으로 분석할 수 있습니다.

주요 구성 요소:

• 객체(Objects): 서로 메시지를 주고받는 주체
• 메시지(Messages): 객체 간 호출이나 데이터 전달
• 생명선(Lifeline): 객체가 존재하는 시간의 흐름
• 활성 구간(Activation Bar): 객체가 실제로 동작 중인 기간

실무 활용 예시:

로그인 프로세스의 상호작용 다이어그램:

sequenceDiagram
    participant User as 🧑 사용자
    participant Browser as 🌐 브라우저
    participant Server as 🖥️ 서버
    participant DB as 🗄️ 데이터베이스

    User->>Browser: 로그인 정보 입력 (email, password)
    Browser->>Server: POST /api/login 요청
    Server->>DB: 사용자 인증 쿼리 실행 (SELECT * FROM users)
    DB-->>Server: 사용자 정보 반환
    Server-->>Browser: 로그인 성공 응답 (JWT 토큰)
    Browser-->>User: 로그인 완료 및 대시보드 이동

이 다이어그램을 통해 “요청이 어떻게 전달되고, 어디서 검증되며, 어떤 순서로 응답이 오는지”를 한눈에 파악할 수 있습니다.
실제 시스템 통신 흐름, API 설계, 비동기 호출 구조 등을 문서화할 때 자주 사용됩니다.

커뮤니케이션 다이어그램 (Communication Diagram)

커뮤니케이션 다이어그램(Communication Diagram)은 객체 간 상호작용(interaction)을 표현한다는 점에서 시퀀스 다이어그램(Sequence Diagram)과 매우 유사합니다.

그러나 시퀀스 다이어그램이 시간의 흐름(time ordering)에 초점을 맞춘다면, 커뮤니케이션 다이어그램은 객체 간 구조적 관계(structural relationship)에 더 중점을 둡니다.

즉, “누가 누구와 연결되어 있고, 어떤 메시지를 주고받는가”를 네트워크 형태로 시각화하는 다이어그램이에요.

주요 구성 요소:

• 객체(Objects): 통신의 주체
• 링크(Links): 객체 간 연결 관계
• 메시지(Messages): 상호작용을 나타내는 호출 (번호로 순서 표시)

실무 활용 예시:

주문 처리 과정의 커뮤니케이션 다이어그램:

graph LR
    A[고객 Client]
    B[주문 서비스 OrderService]
    C[재고 서비스 InventoryService]
    D[결제 서비스 PaymentService]

    A -- 1. 주문 요청 --> B
    B -- 2. 재고 확인 요청 --> C
    C -- 3. 재고 상태 반환 --> B
    B -- 4. 결제 처리 요청 --> D
    D -- 5. 결제 승인 결과 --> B
    B -- 6. 주문 완료 응답 --> A

각 화살표에는 호출 순서가 숫자로 표시되며,
이 번호를 통해 실행 순서를 이해할 수 있습니다.
커뮤니케이션 다이어그램은 “객체 간 관계 구조를 동시에 보고 싶을 때” 특히 유용합니다.

실무에서 UML 다이어그램 활용하기

어떤 다이어그램을 언제 사용할까요?

각 UML 다이어그램은 특정 목적에 최적화되어 있습니다. 상황에 따라 적절한 다이어그램을 선택하는 것이 중요해요.

프로젝트 초기 단계:

• 유스케이스 다이어그램: 요구사항 수집
• 클래스 다이어그램: 시스템 구조 설계

상세 설계 단계:

• 시퀀스 다이어그램: 상호작용 흐름 정의
• 활동 다이어그램: 비즈니스 프로세스 모델링
• 상태 머신 다이어그램: 객체 상태 정의

구현 및 배포 단계:

• 컴포넌트 다이어그램: 모듈 구조 정의
• 배포 다이어그램: 인프라 구성

UML 도구 추천

실무에서 UML 다이어그램을 그릴 때 다음과 같은 도구들을 활용할 수 있습니다:

• draw.io: 무료이며 사용이 간편함
• Lucidchart: 협업 기능이 우수함
• PlantUML: 코드 기반 다이어그램 생성
• StarUML: 전문적인 UML 모델링 도구

특히 PlantUML은 텍스트로 다이어그램을 작성할 수 있어, 버전 관리가 쉽고 개발자들에게 친숙합니다.

UML로 더 나은 소프트웨어 설계하기

UML 다이어그램은 단순한 그림이 아닙니다. 복잡한 시스템을 명확히 표현하고, 팀원들과 효과적으로 소통하며, 유지보수 가능한 소프트웨어를 만드는 강력한 도구예요.

이 글에서 소개한 다양한 UML 다이어그램 종류를 이해했다면, 이제 실제 프로젝트에 적용해볼 차례입니다. 처음부터 완벽한 다이어그램을 그리려고 하지 마세요. 작은 부분부터 시작하여 점차 확장해나가는 것이 중요합니다.

다음 프로젝트를 시작할 때, 코드를 작성하기 전에 먼저 클래스 다이어그램이나 시퀀스 다이어그램을 그려보세요. 시스템 설계에 대한 새로운 통찰을 얻을 수 있을 거예요. UML을 마스터하면 더 견고하고 확장 가능한 소프트웨어를 설계할 수 있습니다.

궁금한 점이 있거나 실무에서 UML을 어떻게 활용하고 있는지 공유하고 싶다면, 댓글로 남겨주세요. 함께 배우고 성장하는 개발자 커뮤니티를 만들어갑시다!

References

• uml-diagrams.org