천객만래 [千客萬來] (It has an interminable succession of visitors)

ICONIX Process

IT-개발 2019. 12. 30. 09:35

ICONIX Process

 

ICONIX 프로세스는 사용하기 쉬운 개방형 개체 모델링 프로세스입니다. 최소한의 사용 사례 중심이며 민첩합니다. 이 프로세스는 사용 사례와 코드 사이의 영역에 중점을 둡니다. 시작하는 라이프 사이클의 시점에서 어떤 일이 발생해야하는지에 중점을두고 있습니다. 일부 사용 사례가 시작되었으므로 이제는 우수한 분석 및 설계가 필요합니다.

 

GUI 스토리보드가 먼저 시작되는 것을 볼 수 있다.

 

 

 

간단히 말해서 ICONIX 프로세스

이 섹션에서는 프로세스 자체에 대해 설명합니다. 간단히 말해서, ICONIX 프로세스는 가능한 적은 단계로 유스 케이스에서 코드로 안정적으로 전환하는 방법을 설명합니다.

그림 3-3 은 ICONIX 프로세스의 여러 활동이 어떻게 결합되는지 보여줍니다.


그림 3-3 : ICONIX 프로세스

ICONIX 프로세스는 다음 단계로 나눌 수 있습니다 ( 굵게 표시된 항목 은 각 단계에서 수행하는 구체적 모델링 활동입니다).

  • 1 단계 : 실제 도메인 개체 식별 ( 도메인 모델링 )

  • 2 단계 : 행동 요구 사항 정의 ( 사용 사례 )

  • 3 단계 : 견고성 분석  수행 하여 사용 사례를 명확하게하고 도메인 모델의 차이를 식별합니다.

  • 4 단계 : 객체에 동작을 할당합니다 ( 시퀀스 다이어그램 ).

  • 5 단계 : 정적 모델을 완료하십시오 ( 클래스 다이어그램 ).

  • 6 단계 : 코드 작성 / 생성 ( 소스 코드 )

  • 7 단계 : 시스템 및 사용자 수락 테스트를 수행합니다.

이 프로세스를 분석 및 설계 모델링 활동에 대한 서신으로 보내면 프로젝트가 고객의 요구 사항을 충족하고 합리적인 시간 내에이를 수행 할 수있는 좋은 기회가됩니다.

다음 섹션에서 이러한 각 단계를 자세히 살펴보면 프로젝트 계획에서보기 좋게 나타나는 4 가지 주요 이정표에 주목할 것입니다.이 계획은 유용한 계획 체크 포인트이기도합니다. "이 XYZ 작업이 완료되었으므로 이제 다음 단계로 넘어갑니다"라고 말하고 설명하십시오.

  • 이정표 1 : 요구 사항 검토

  • 이정표 2 : 예비 설계 검토

  • 이정표 3 : 상세 / 중요한 설계 검토

  • 이정표 4 : 배달

1 단계 : 실제 도메인 객체 식별

이 단계를 올바르게 수행하는 것은 전체 프로젝트에서 가장 중요한 부분 일 것입니다. 프로젝트의 다른 모든 것 (요구 사항, 디자인, 코드 등)이 절대적으로 구축되는 견고한 기반을 구축하기 때문입니다.

이 단계는 다음 단계로 세분 될 수 있습니다.

  1. 실제 도메인 개체와 이러한 개체 간의 일반화 및 집계 관계를 식별하십시오. 높은 수준의 클래스 다이어그램을 그리기 시작하십시오.

  2. 가능하다면 제안 된 시스템을 신속하게 프로토 타이핑하거나 리엔지니어링 할 레거시 시스템에 대한 실질적인 정보를 수집하십시오.

이 단계를 마치면 프로젝트의 모든 사용자 (고객, 프로그래머, 분석가, 테스터 및 최종 사용자)가 공통 어휘로 공유하고 사용할 수있는 합리적으로 올바른 도메인 모델이 있어야합니다. 도메인 모델은 프로젝트가 진행됨에 따라 계속 발전하고 성장할 것입니다 (그리고 비즈니스 영역을 캡처하는 더 간단한 것으로 변경 될 수 있기를 바랍니다).

도메인 모델은 문제 영역 엔터티 클래스를 기반으로하는 정적 모델 (클래스 다이어그램)을 솔루션 공간이 아닌 예비 추측입니다. 클래스에는 속성이나 작업이 표시되지 않습니다.

도메인 모델에는 시스템이 해결하도록 설계된 문제와 관련된 실제 사물과 개념이 포함되어 있습니다. 우리는 도메인 모델을 만들 때 비즈니스를 형성하는 개체와 행동의 표현을 만들고 프로젝트가 해결하려는 문제에 중점을 둡니다. 프로젝트에 대해 생성 한 초기 도메인 모델은 완벽하지 않습니다. 문제 영역에 대한 이해가 발전함에 따라 프로젝트 전체에서 발전 할 것입니다.

실제로 도메인 모델로 갈 개체를 어떻게 식별합니까? 여러 가지 기술이 있으며 그중 가장 중요한 것은 단순히 자신의 경험과 판단을 사용하는 것입니다. 그러나 실제로 고착 된 경우 문법 검사 기술 을 사용하는 것이 좋습니다 . [ 6. ] 사용 가능한 관련 자료 (요구 사항, 비즈니스 용어집 등)를 빠르게 통과하면서 명사와 동사를 강조 표시합니다. . 관련 자료에는 고객 및 시스템의 최종 사용자와의 자체 인터뷰도 포함되어야합니다. 이러한 토론은 종종 모호성을 해결하고 추가 도메인 객체를 식별하는 데 도움이됩니다.

작업이 진행됨에 따라 목록을 수정 한 후

  • 명사와 명사구는 클래스와 속성이됩니다.

  • 동사와 동사구는 연산과 연관이됩니다.

  • 소유 어구는 명사가 클래스가 아닌 속성이어야 함을 나타냅니다.

물론 이러한 항목은 일반적인 규칙 만 나타냅니다 (단, 유용한 규칙이지만). 예를 들어, 일부 동사는 결국 조작이 아닌 객체가됩니다 (특히 비즈니스 프로세스를 모델링하거나 관리자 또는 컨트롤러, 클래스를 식별 한 경우).

도메인 모델을 계속 반복하고 세분화해야하지만 이것이 명사와 동사를 무기한으로 계속 연마해야한다는 의미는 아닙니다. 목표는 사용 사례 텍스트 내에서 적절하게 명사 역할을 할 오브젝트 이름 용어집을 작성하는 것 입니다.

초기 도메인 모델을 구축하기위한 시간 예산을 설정하는 것이 좋습니다 (예를 들어, 아침이나 몇 시간까지 걸리는 공동 작업장으로 제한). 도메인 모델은 중요하지만 프로젝트의 나머지 부분이 시작되는 것을 방지하기를 원하지 않습니다! 일반적으로 몇 시간 내에 도메인 클래스의 가장 중요한 80 %를 찾을 수 있습니다. 사용 사례를 진행하면서 나머지 클래스를 발견하므로 완벽하게 얻을 필요는 없습니다.

2 단계 : 행동 요구 사항 정의

지금까지 수집 한 것처럼 ICONIX 프로젝트의 동작 요구 사항은 사용 사례에 의해 정의됩니다. 사용 사례는 높은 수준의 요구 사항 (이전 단계에서 논의 됨)을 확장하고 사용자 상호 작용 측면에서 시스템의 동작 방식을 정의합니다. 이 책의 뒷부분에서 설명 하겠지만,이 단계는 세부적인 상호 작용 디자인 (특히 페르소나 분석, 12 장 참조)으로 보강되는 것이 좋습니다.

이 단계는 다음 단계로 세분 될 수 있습니다.

  1. 사용 사례 다이어그램을 사용하여 사용 사례를 식별하십시오.

  2. 사용 사례를 그룹으로 구성하십시오. 이 조직을 패키지 다이어그램으로 캡처하십시오.

  3. 기능 요구 사항을 사용 사례 및 도메인 오브젝트에 할당하십시오. (이 단계는 프로젝트의 형식에 따라 선택 사항입니다.)

  4. 사용 사례에 대한 설명을 작성하십시오 (즉, 이동 빈도가 적은 경로 및 오류 조건에 대한 주류 및 대체 과정을 나타내는 기본 행동 과정).

유스 케이스 모델링을 완료 한 시점을 어떻게 알 수 있습니까? 다음을 달성하면 개발 프로세스의 다음 단계로 넘어갈 준비가되었습니다.

  • 시스템의 원하는 기능  모두 설명하는 사용 사례를 구축했습니다 .

  • 각 사용 사례에 대해 적절한 대체 조치 과정과 함께 기본 조치 과정에 대한 명확하고 간결한 설명을 작성했습니다.

  • 앞선을 사용하고 구문 (또는 일반적으로 선호하는 구문)을 사용하여 둘 이상의 사용 사례에 공통적 인 시나리오를 제외했습니다.

이정표 1 : 요구 사항 검토

3 단계 : 도메인 모델에서 사용 사례를 명확하게하고 간격을 식별하기 위해 견고성 분석 수행

이것이 프로젝트의 최종 분석 단계입니다. 이 장의 뒷부분에서 볼 수 있듯이 견고성 분석은 ICONIX 프로세스에서 중요한 역할을합니다. 핵심은 견고성 다이어그램입니다 ( 그림 3-4 참조 ).


그림 3-4 : 견고성 다이어그램 예

견고성 분석에는 유스 케이스의 텍스트를 통해 작업하며, 지금까지 발견 한 오브젝트를 사용하여 특정 유스 케이스를 구현하기 위해 일부 소프트웨어를 설계하는 방법을 미리 살펴 봅니다. 이 액티비티의 주요 목적 중 하나는 필요한 객체가 모두없는 경우를 찾아 클래스 다이어그램에 추가하는 것입니다.

견고성 분석 단계는 다음 단계로 세분됩니다.

  1. 견고성 다이어그램을 그립니다. 각 사용 사례

    1. 명시된 시나리오를 수행하는 첫 번째 컷 개체를 식별하십시오. UML Objectory 스테레오 타입을 사용하십시오 ( 그림 3-5 참조 ).


      그림 3-5 : 견고성 분석 고정 관념

    2. 발견 할 때 새 오브젝트 및 속성으로 도메인 모델 클래스 다이어그램을 업데이트하십시오.

    3. 견고성 다이어그램과 일치하도록 유스 케이스 텍스트를 업데이트하십시오.

  1. 프로젝트의 분석 단계 완료를 반영하도록 클래스 다이어그램 업데이트를 완료하십시오.

이정표 2 : 예비 설계 검토

Ivar Jacobson 은 1991 년 OO의 세계  견고성 분석 개념을 도입 했습니다. 견고성 분석에는 각 사용 사례의 설명 텍스트를 분석하고 사용 사례에 참여할 첫 번째 추측 개체 집합을 식별 한 다음이를 분류합니다. 다음 세 가지 객체 유형으로

  • 경계 객체- 액터가 시스템과 통신하는 데 사용합니다.

  • 엔티티 객체 (이라고도 실체 보통), 도메인 모델 객체.

  • 경계 객체와 엔티티 객체 사이의 "접착제"역할을하는 제어 객체 ( 컨트롤러 라고도 함 ). 때때로 이들은 실제 Control 객체이지만 대부분은 단순히 함수에 대한 동사 자리 표시자를 나타냅니다.

이 간단하지만 매우 유용한 기술은 (분석 사이의 중요한 링크 역할을 무엇 )과 디자인합니다 ( 방법 ). 이 책의 뒷부분에서 견고성 분석의 몇 가지 예를 살펴 보겠습니다.

이 세 가지 객체 유형은 MVC (Model-View-Controller) 디자인 패턴으로 잘 변환되며 [ 7. ] 클라이언트-서버 및 GUI 개발에 많이 사용됩니다. 엔터티 개체는 Model에 의해 전달되고 경계 개체는 View 에서 구성되며 Control 개체는 Controller에서 구성 됩니다. 예를 들어, 3 계층 웹 응용 프로그램에서 경계 (또는보기) 개체는 JSP 페이지 일 수 있습니다 (때로는 프레젠테이션 계층 이라고도 함 ). 엔티티 (즉, 데이터)는 데이터베이스, 일반적으로 비즈니스 오브젝트 계층을 통해 제공됩니다. 전체 엔칠 라다를 하나로 묶는 Control 객체는 애플리케이션 서버에 내장 된 비즈니스 로직 계층에 의해 제공됩니다.

리치 클라이언트 GUI 애플리케이션에서 경계 (또는보기) 오브젝트는 테이블 또는 콤보 상자 컴포넌트 (예 : Java Swing, JTable 또는 JComboBox) 일 수 있으며 Model 오브젝트는 다음과 같은 데이터 모델 (예 : DefaultTableModel)입니다. 구성 요소가 표시 할 엔티티를 제공하고 제어 코드는 UI 이벤트 (예 : 테이블을 위아래로 스크롤)를 처리하여 모델에서보기를 표시해야하는 데이터를 판별합니다.

프로젝트의 기능이 향상됨에 따라 (또는 배포 된 시스템에 동시에 액세스하는 사용자 수와 같은 다른 방식으로) 과제를 충족하도록 아키텍처를 확장해야합니다. 이는 종종 기능을 별도의 계층으로 분할 한보다 복잡한 아키텍처로 이어집니다 (예 : 애플리케이션 로직의 다른 영역이 다른 계층으로 분리 될 수 있음). 이것은 BCE (Boundary-Control-Entity) 아키텍처 (또는 MVC 아키텍처)의 확장으로 볼 수 있으므로 ICONIX 프로세스는 여전히보다 복잡한 아키텍처에 쉽게 적용 할 수 있습니다 (즉, 프로세스는 프로젝트).

4 단계 : 객체에 동작 할당

이 단계는 프로젝트의 디자인 단계가 시작되는 곳입니다. 이 단계에서 선택한 주요 다이어그램은 시퀀스 다이어그램 ( 그림 3-6 참조 )이지만 추가 다이어그램 및 활동 (예 : 상태 다이어그램, 활동 다이어그램 또는 엄격한 테스트 중심 방법론에 따른 단위 테스트)을 사용할 수도 있습니다. 제 12 장)


그림 3-6 : 예제 시퀀스 다이어그램

이 단계는 각 사용 사례에 대해 다음 단계로 세분화됩니다.

  1. 호출 할 오브젝트와 연관된 메소드간에 전달해야하는 메시지를 식별하십시오.

  2. 사용 사례 텍스트가 왼쪽으로 내려 가고 시퀀스 정보가 오른쪽에있는 시퀀스 다이어그램을 그립니다.

  3. 클래스 다이어그램을 찾은대로 속성 및 조작으로 계속 업데이트하십시오.

시퀀스 다이어그램에서 클래스에 작업을 할당하지 않으면 인생의 주요 임무는 무시하는 것입니다.

각 사용 사례마다 하나의 시퀀스 다이어그램을 만듭니다. 기억해야 할 중요한 점은 단일 유스 케이스에서 상호 작용을 맵핑하기 위해 많은 다이어그램으로 혼란에 빠지는 것을 원하지 않기 때문입니다. 그렇게하면 분석 마비가 심해지므로 사용 사례에 대해 여러 가지 대안 시나리오가 있더라도 모든 것을 하나의 시퀀스 다이어그램에 배치하십시오.

이것이 유스 케이스 텍스트에 대한 두 단락 규칙의 이유입니다. 모든 것을 하나의 시퀀스 다이어그램에 맞출 수 있습니다. 이 접근법의 결과는 다이어그램이 너무 조각화되는 것을 방지한다는 것입니다. 즉, 단일 다이어그램을 읽으면 전체 사용 사례를 해결했는지 확인할 수 있습니다. 조각이 너무 많으면 모든 사용 사례를 확보하기가 어렵습니다.

5 단계 : 정적 모델 완료

이 단계의 제목에서 알 수 있듯이 여기서 핵심 설계 아티팩트는 하나 이상의 클래스 다이어그램으로 구성된 정적 모델입니다 ( 그림 3-7 참조 ).


그림 3-7 : Part 2에 제시된 맵렛 프로젝트에 대한 예제 클래스 다이어그램

이 단계는 다음 단계로 세분됩니다.

  1. 자세한 설계 정보 (예 : 가시성 값 및 패턴)를 추가하십시오.

  2. 디자인이 식별 한 모든 요구 사항을 충족하는지 팀과 확인하십시오.

이정표 3 : 상세 / 중요한 설계 검토

정적 모델은 도메인 모델의 더 거칠고 상세한 버전이며 더 자세한 구현 정보가 포함되어 있습니다. 정적 모델에는 매우 상세한 추상화 수준에 있고 시퀀스 다이어그램과 일치하는 자세한 클래스 다이어그램 (아마도 소스 코드에서 리버스 엔지니어링 될 수도 있지만 반드시 필요한 것은 아님)이 있습니다.

모델링 질문 : 정식 모델을 가질 때까지 메인 모델 다이어그램을 재사용하고 간단하게 추가해야합니까?

프로젝트가 하나의 릴리스 (또는 최대 두 개의 릴리스) 만 거치는 것을 알고 있다면이 접근법이 잘 작동합니다. 그러나 짧은 릴리스가 많고 각 릴리스가 시작될 때 도메인 모델링 활동이있는 민첩한 프로젝트에서는 도메인 모델과 클래스 다이어그램에 대해 별도의 다이어그램을 유지해야합니다. 클래스 다이어그램은 여전히 ​​원래 도메인 모델에서 성장하고 발전하지만 (이 접근 방식은 ICONIX 프로세스의 기본), 다이어그램은 별도로 유지됩니다.

도메인 모델은 비즈니스 도메인에 대한 현재의 이해 (예 : 분석 수준 아티팩트)를 반영하는 반면, fleshed out 클래스 다이어그램 (여러 개가있을 수 있음)은 집합 적으로 세부적인 디자인 아티팩트입니다. 비즈니스 도메인에 대한 이해가 발전함에 따라 이전 단계의 설계 세부 사항 (적어도 아직은 아님)을 고려하여 속도 저하없이 도메인 모델을 신속하게 업데이트하고 리팩토링 할 수 있어야합니다. 디자인 단계).

물론 이것은 업데이트 할 추가 다이어그램이 있다는 것을 의미하지만, 절충안입니다. 이점은 도메인 모델을 최신 상태로 유지하는 것이 훨씬 쉽고 읽기가 더 쉽다는 것입니다 (디자인 세부 사항 및 디자인 결정 기록에 의해 혼란 스럽기 때문).

도메인 모델과 클래스 다이어그램이 동일한 다이어그램 인 경우 새로운 비즈니스 이해에 비추어 도메인 모델을 업데이트하기가 더 어렵습니다. 모든 중간 단계를 거치지 않고 세부 설계를 효과적으로 수정하기 때문입니다 ( 견고성 분석, 시퀀스 다이어그램 등).

6 단계 : 코드 작성 / 생성

물론이 단계는 프로그래머가 디자인을 취하고 코드를 작성하기 시작하는 단계입니다. 프로그래머는 모든 설계 단계 (이상적으로는 디자이너도 프로그래머이기도 함)에 참여해야 디자인이 시스템이 구현 될 기술의 현실에 어느 정도 근거가 있어야합니다.

이 단계는 다음 단계로 세분됩니다.

  1. 코드를 작성 / 생성하십시오.

  2. 단위 및 통합 테스트를 수행하십시오.

ICONIX 프로세스를 테스트 중심 접근 방식 (12 장 참조)과 결합하면 단위 테스트가 코드 전에 작성됩니다. 여기서 중요한 점은 프로그래머가 통합 테스트를 포함하여 자체 테스트를 수행하고 있다는 것입니다.

7 단계 : 시스템 및 사용자 수락 테스트 수행

이 단계에서는 프로그래밍 팀과 다른 그룹 (이상적으로는 QA 팀)이 유스 케이스를 후자의 블랙 박스 테스트 케이스로 사용하여 시스템 및 사용자 승인 테스트를 수행합니다.

이정표 4 : 배달

[ 6. ] Kurt Derr, OMT 적용 : 객체 모델링 기법 사용에 대한 실용적인 단계별 가이드 (New York : Cambridge University Press, 1995).

[ 7. ] http://java.sun.com/blueprints/patterns/MVC.html을 참조하십시오 .

출처: http://users.nagafix.co.uk/~mark/025.html

ICONIX Process in a Nutshell

In this section, we describe the process itself. In a nutshell, ICONIX Process describes how to get from use cases to code reliably, in as few steps as possible.

Figure 3-3 shows how the different activities in ICONIX Process fit together.


Figure 3-3: ICONIX Process

ICONIX Process can be broken down into the following steps (the items in bold are the concrete modeling activities that you perform at each step):

  • Step 1: Identify your real-world domain objects (domain modeling).

  • Step 2: Define the behavioral requirements (use cases).

  • Step 3: Perform robustness analysis to disambiguate the use cases and identify gaps in the domain model.

  • Step 4: Allocate behavior to your objects (sequence diagrams).

  • Step 5: Finish the static model (class diagram).

  • Step 6: Write/generate the code (source code).

  • Step 7: Perform system and user-acceptance testing.

If you follow this process to the letter for your analysis and design modeling activities, then your project will stand a good chance of meeting the customer’s requirements—and doing so within a reasonable time frame.

As we walk through each of these steps in detail in the sections that follow, we’ll note four key milestones that tend to look good on a project plan (they’re also useful planning checkpoints, as they provide key stages where you can both say and demonstrate that “this XYZ work is done, so now we’re moving on to the next stage”).

  • Milestone 1: Requirements Review

  • Milestone 2: Preliminary Design Review

  • Milestone 3: Detailed/Critical Design Review

  • Milestone 4: Delivery

Step 1: Identify Your Real-World Domain Objects

Getting this step right is possibly the most important part of the whole project, because it establishes a solid foundation upon which absolutely everything else in the project (requirements, design, code, and so forth) is built.

This step can be further subdivided into the following steps:

  1. Identify your real-world domain objects and the generalization and aggregation relationships among those objects. Start drawing a high-level class diagram.

  2. If it’s feasible, do some rapid prototyping of the proposed system, or gather whatever substantive information you have about the legacy system you’re reengineering.

When this step is finished, you should have a reasonably correct domain model, which everyone on the project (the customer, the programmers, the analysts, the testers, and even the end users) can share and use as a common vocabulary. The domain model will continue to evolve and grow (and hopefully be whittled down to something simpler that still captures the business domain) as the project progresses.

The domain model is a preliminary guess at the static model (class diagrams) based strictly on problem-domain entity classes—no solution-space stuff. No attributes or operations are shown on the classes.

The domain model contains real-world things and concepts related to the problem that the system is being designed to solve. When we create a domain model, we’re creating a representation of the objects and actions that form the business and are focused on the problem that the project is attempting to solve. The initial domain model that you create for any project will never be perfect. It will evolve throughout the project as your understanding of the problem domain evolves.

How do you actually identify objects to go in the domain model? There are a number of techniques, the most important of which is simply to use your own experience and judgment. A good starting point if you’re really stuck, however, is to use the grammatical inspection technique:[6.] quickly pass through the available relevant material (requirements, business glossaries, and so forth), highlighting nouns and verbs as you go. Note that the relevant material should also include your own interviews with the customer and end users of the system. Often these discussions help more than anything else to resolve ambiguities and identify further domain objects.

After refining the lists as work progresses, you should find that

  • Nouns and noun phrases become classes and attributes.

  • Verbs and verb phrases become operations and associations.

  • Possessive phrases indicate that nouns should be attributes rather than classes.

These items represent only a general rule, of course (though a darned useful one). You might well find, for example, that some verbs eventually become objects rather than operations (particularly if you’re modeling a business process, or if you’ve identified a manager, or controller, class).

You should continue to iterate and refine the domain model, but this doesn’t mean that you should keep grinding nouns and verbs indefinitely. The goal is to build a glossary of object names that will serve as the nouns, as appropriate, within your use case text.

It’s worth establishing a time budget for building your initial domain model (e.g., restrict it to a collaborative workshop taking no more than a morning, or even just a couple of hours). The domain model is important, but you don’t want it to prevent the remainder of the project from ever getting started! You can generally find the most important 80% of your domain classes within a couple of hours—and that’s good enough to get going. You don’t have to get it perfect, because you’ll discover the remaining classes as you work through the use cases.

Step 2: Define the Behavioral Requirements

As you’ve probably gathered by now, the behavioral requirements in an ICONIX project are defined by use cases. The use cases expand on the high-level requirements (discussed in the previous step) and define how the system will behave in terms of user interactions. As we’ll discuss later in this book, this step benefits from being augmented with detailed interaction design (especially persona analysis; see Chapter 12).

This step can be further subdivided into the following steps:

  1. Identify your use cases using use case diagrams.

  2. Organize the use cases into groups. Capture this organization in a package diagram.

  3. Allocate functional requirements to the use cases and domain objects. (This step is optional depending on the formality of the project.)

  4. Write descriptions of the use cases (i.e., basic courses of action that represent the mainstream and alternative courses for less frequently traveled paths and error conditions).

How do you know when you’ve finished use case modeling? You’re ready to move to the next phases of the development process when you’ve achieved the following:

  • You’ve built use cases that together account for all of the system’s desired functionality.

  • You’ve produced clear and concise written descriptions of the basic course of action, along with appropriate alternative courses of action, for each use case.

  • You’ve factored out scenarios common to more than one use case, using the precedes and invokes constructs (or whichever constructs you generally prefer using).

Milestone 1: Requirements Review

Step 3: Perform Robustness Analysis to Disambiguate the Use Cases and Identify Gaps in the Domain Model

This is the final analysis step in the project. As you’ll see later in this chapter, robustness analysis plays a key role in ICONIX Process. At its core is the robustness diagram (see Figure 3-4).


Figure 3-4: Example robustness diagram

Robustness analysis involves working through the text of a use case and taking a preliminary peek at how you might design some software to implement a given use case, using the objects you’ve discovered up to this point. One of the main purposes of this activity is to discover when you don’t have all the objects you need, and then add them to your class diagram.

The robustness analysis step is further subdivided into the following steps:

  1. Draw robustness diagrams. For each use case

    1. Identify a first cut of objects that accomplish the stated scenario. Use the UML Objectory stereotypes (see Figure 3-5).


      Figure 3-5: Robustness analysis stereotypes

    2. Update your domain model class diagram with new objects and attributes as you discover them.

    3. Update (disambiguate) the use case text so that it matches the robustness diagram.

  1. Finish updating the class diagram so that it reflects the completion of the analysis phase of the project.

Milestone 2: Preliminary Design Review

Ivar Jacobson introduced the concept of robustness analysis to the world of OO in 1991. Robustness analysis involves analyzing the narrative text of each of your use cases and identifying a first-guess set of objects that will participate in the use case, and then classifying these objects into the following three object types:

  • Boundary objects, which actors use in communicating with the system.

  • Entity objects (also referred to as entities), which are usually objects from the domain model.

  • Control objects (also referred to as controllers), which serve as the “glue” between Boundary objects and Entity objects. Sometimes these are real Control objects, but most of the time they simply represent verb placeholders for functions.

This simple but highly useful technique serves as a crucial link between analysis (the what) and design (the how). We’ll walk through several examples of robustness analysis later in this book.

These three object types translate well into the Model-View-Controller (MVC) design pattern,[7.] which is used heavily in both client-server and GUI development. Entity objects are delivered by the Model, Boundary objects form the View, and Control objects form the Controller. For example, in a three-tier web application, a Boundary (or View) object could be a JSP page (sometimes also referred to as the presentation layer); the entities (i.e., the data) would be served up by a database, usually via a business object layer; and the Control object that binds the whole enchilada together would be provided by a business logic layer housed in an application server.

In a rich-client GUI application, a Boundary (or View) object could be a table or combo box component (e.g., in Java Swing, a JTable or JComboBox), the Model object would be the data model (e.g., DefaultTableModel) that serves up the entities to be displayed by the component, and the Control code would handle the UI events (e.g., scrolling up and down through the table) to determine which data from the model the view needs to display.

As projects grow in functionality (or in other ways, such as the number of users accessing the deployed system concurrently), the architecture must scale up to meet the challenge. This often leads to a more complex architecture, typically with functionality divided into separate layers (e.g., different areas of application logic might be separated out into different layers). This can be viewed as an extension of the Boundary-Control-Entity (BCE) architecture (or the MVC architecture), so ICONIX Process can still readily be applied to more complex architectures (i.e., the process can scale up to meet the demands of your project).

Step 4: Allocate Behavior to Your Objects

This step is where the design phase of the project begins. Our main diagram of choice for this step is the sequence diagram (see Figure 3-6), although you might also use additional diagrams and activities (such as state diagrams, activity diagrams, or unit tests following a strict test-driven methodology; see Chapters 12) as you see fit.


Figure 3-6: Example sequence diagram

This step is further subdivided into the following steps for each use case:

  1. Identify the messages that need to be passed between objects and the associated methods to be invoked.

  2. Draw a sequence diagram with use case text running down the left side and design information on the right.

  3. Continue to update the class diagram(s) with attributes and operations as you find them.

If you’re not allocating operations to classes on the sequence diagram, you’re ignoring its primary mission in life.

For each use case, you create one sequence diagram. This is an important point to remember, because you don’t want to end up getting bogged down with many diagrams just to map out the interaction in a single use case. Doing so would give you a nasty case of analysis paralysis so, even if you have multiple alternative scenarios on your use cases, put everything on the one sequence diagram.

This is the reason for the two-paragraph rule on use case text: you can fit the whole thing on one sequence diagram. The net result of this approach is that it prevents the diagrams from becoming too fragmented. It means you can validate that you’ve addressed the whole use case by reading a single diagram. Too many fragments make it hard to be sure you got all of the use case.

Step 5: Finish the Static Model

As the title of this step suggests, the key design artifact here is the static model, which is made up of one or more class diagrams (see Figure 3-7).


Figure 3-7: Example class diagram for the mapplet project presented in Part 2

This step is further subdivided into the following steps:

  1. Add detailed design information (e.g., visibility values and patterns).

  2. Verify with your team that your design satisfies all the requirements you’ve identified.

Milestone 3: Detailed/Critical Design Review

The static model is the grittier, more detailed version of the domain model, and it contains more implementation details. The static model has detailed class diagrams (perhaps even reverse engineered from the source code, but not necessarily) that are at a very detailed abstraction level and match the sequence diagrams.

MODELING QUESTION: SHOULD WE REUSE THE DOMAIN MODEL DIAGRAM AND SIMPLY KEEP ADDING TO IT UNTIL WE HAVE OUR STATIC MODEL?

If you know that your project is going to go through only one release (or a couple of releases at most), this approach serves nicely. However, in an agile project with lots of short releases and with domain modeling activities at the start of each release, it pays to keep separate diagrams for the domain model and class diagrams. The class diagram still grows and evolves from the original domain model (this approach is fundamental to ICONIX Process), but the diagrams are kept separate.

The domain model reflects our current understanding of the business domain (i.e., it’s an analysis-level artifact), whereas the fleshed-out class diagrams (there may be several) are collectively a detailed design artifact. As our understanding of the business domain evolves, we need to be able to quickly update and maybe also refactor the domain model, without getting slowed down by having to consider design details from previous iterations (at least not yet—that comes when we get to the design stage).

Of course, this means that you have an extra diagram to update, but it’s a trade-off. The benefit is that it’s much easier to keep the domain model up to date, and it’s easier to read (because it’s uncluttered by design details and records of design decisions).

If the domain model and the class diagram are the same diagram, it’s also more difficult to update the domain model in light of new business understanding, because you’re in effect modifying the detailed design without going through all the intermediate steps to get there (robustness analysis, sequence diagrams, and so forth).

Step 6: Write/Generate the Code

This step is, of course, where the programmers take the design and start to code from it. The programmers should have been involved in all the design steps (ideally the designers are also the programmers), so that the design has some grounding in the reality of the technologies in which the system will be implemented.

This step is subdivided into the following steps:

  1. Write/generate the code.

  2. Perform unit and integration testing.

If you are combining ICONIX Process with a test-driven approach (see Chapter 12), then the unit tests will be written before the code. An important point here is that the programmers are doing their own testing, including integration testing.

Step 7: Perform System and User-Acceptance Testing

For this stage, a different group from the programming team (ideally a separate QA team) performs system and user-acceptance testing, using the use cases as black-box test cases for the latter.

Milestone 4: Delivery

[6.]Kurt Derr, Applying OMT: A Practical Step-By-Step Guide to Using the Object Modeling Technique, (New York: Cambridge University Press, 1995).

[7.]See http://java.sun.com/blueprints/patterns/MVC.html.

 

 

'IT-개발' 카테고리의 다른 글

IntelliJ Golang 연동할 때 에러  (0) 2020.01.17
프로젝트 3요소  (0) 2020.01.15
ICONIX Process  (0) 2019.12.30
프로그래머로서 나의 발전 단계  (0) 2019.12.18
자바스크립트에서 ==., ===  (0) 2019.06.16
How to disable "Submit" button and multiple submissions?  (0) 2019.05.25
Posted by 사용자 SB패밀리

댓글을 달아 주세요

 신용관리 10계명


1 주거래 은행을 만들어라!  

 주거래 은행이란 자신이 제일 많이 이용하는 은행을 말하는 것입니다. 주거래 은행에 거래를 집중해서 거래실적을 많이 쌓는 것이 좋습니다. 왜냐하면 고객의 신용을 평가할 때 해당 은행과의 거래실적이 중요하게 반영되기 때문입니다. 그러므로 카드대금결제, 공과금이체, 통신대금납부, 월급이체 등 금융거래를 한 은행에 집중/관리하는 것이 좋습니다. 



2 조회처 정보 발생을 줄여라! 

 금융회사의 CSS(Credit Scoring System)에서는 개인의 신용을 평가할 때, 조회처 정보가 반영되기 때문에 조회처 정보가 많으면 대출이나 카드발급이 거절될 수 있습니다. 

조회처 정보가 많아 신용점수가 떨어지는 이유는, 조회처정보가 갑자기 늘어난 사람의 경우 채권상환 등의 금융거래에 많은 문제가 발생했다는 통계적 결과치가 나타나기 때문입니다. 

즉, 단기간 안에 여러 금융회사를 돌아다니면서 대출을 받거나 카드를 발급받아 현금서비스를 이용하여 자취를 감추거나 이민을 가는 사례가 많아 금융회사의 피해가 많이 발생하기 떄문입니다.



따라서 단순히 대출가능여부가 궁금하여 여러 금융회사 홈페이지를 통해 대출을 신청하게 되면 조회처 정보가 늘어나 추후에 실질적인 대출을 받고자 할 때 조회처정보 과다로 불이익을 받을 수 있으므로 필요 없는 대출신청이나 카드발급신청을 해서 조회처정보를 늘리는 것은 바람직하지 못합니다.   크레딧뱅크에서는 이러한 문제점을 해결하기 위해, 은행에서 운영하는 CSS와 유사한 일반 CSS 서비스를 회원들에게 제공하고 있으니 이를 활용하여, 대출을 신청하기 전, 자신의 신용에 의해 어느정도의 대출금리와 대출금이 결정될지를 가능해보는 것이 필요합니다. 

그 이유는 자기 스스로가 본인의 신용정보를 조회하거나 당사의 일반 CSS 서비스를 무한정 이용해도 조회처정보에 전혀 남지 않기 떄문입니다.

 

3 내게 맞는 카드는 한장만 사용하라! 

 본인에게 혜택이 많이 주어지는 카드를 하나 선택하여 집중하여 사용하는 게 좋습니다. 

거래실적이 좋아 해당 카드사로부터 우량고객으로 평가 받게 되면, 보다 낮은 금리나 유리한 조건으로 대출이 가능하고 대출한도가 증가하는 등 다양한 이점을 누릴 수 있습니다. 

또한 관리가 용이하여 분실, 연체, 대금결제관리가 훨씬 간편해집니다. 



4 카드 대금을 연체하지 말자! 

 연체금액이 적거나 혹은 연체기간이 단 하루라도 개인의 신용은 저하됩니다.

이러한 연체정보는 카드사간에 공유하기 때문에 해당 연체가드의 사용이 정지되면 다른 카드의 사용도 제한받게 됩니다. 또한 연체를 자주하면 신용점수가 낮아져 대출한도가 줄어들거나 재발급이 어려울 수 있습니다. 
 

5 대출금의 만기일을 체크하라! 

 채무를 3개월 이상 연체하면 신용불량자로 등록되어 추가로 신용대출 받기가 어렵습니다.

그러므로 가능하면 연체를 발생시키지 않아야 하고 발생시키더라도 3개월이 넘으면 안 됩니다. 



6 보증시 대출한도, 기간등을 체크하라. 그리고 무분별한 보증은 금물! 

 최근 신용정보에는 보증인정보가 추가되어 금융회사에서도 보증선 내역을 조회할 수 있습니다.

신용거래정보, 불량정보, 조회처정보가 각각의 의미를 가지고 개인의 신용을 평가하는데 중요한 자료로 활용되듯이 앞으로 보증인 정보도 매우 중요하게 고려됩니다.   즉, 보증 선 금액만큼 본인의 신용대출한도가 감소하게 됩니다. 따라서 무분별한 보증은 자제해야 하며, 이미 보증을 섰다면 보증 기간을 체크해 두었다가 기간 만료시 본인 허락 없이 연장되지 않도록 관리해야 합니다. 



7 카드의 현금서비스 이용대금을 미리 갚을 능력이 있다면 선결제를 활용하라! 

 카드대금 연체중이거나 현금서비스를 받았다면 결제일까지 기다리지 말고 미리 결제 혹은 변제하게 되면 그만큼 이자가 감소하게 되고 연체기간도 줄어들게 됩니다. 


8 자동이체를 이용하라! 

 자동이체를 이용하면 자신의 부주의에 의해서 발생할 수 있는 연체를 방지할 수 있습니다. 또한 거래 은행의 경우, 자동이체 고객을 선호하므로 개인 신용을 높이는데 도움이 됩니다. 하지만 자동이체만 믿고 있다가 연체될 수 있으므로 통장잔액을 자주 확인해야 합니다. 


9 영수증을 반드시 보관하라! 

 물품 구입, 연체금 상환 등 후에는 영수증을 꼭 보관해 두어야 합니다. 신용거래취소, 물품 반환, 이중청구시 거래를 입증자료로 활용할 수 있으며 또한 연체금을 상환하였는데 해당 업체의 실수로 미결제로 처리되어 불량정보가 해제되지 않는 경우도 있는데 영수증은 이때 상환을 증명할 수 있는 자료가 됩니다.  



10 변경된 주소는 반드시 통보하라!  

 주소지가 변경되면 은행, 이동통신 등 대금결제 중인 해당 회사에 변경된 주소를 반드시 통보해야 합니다. 나중에 주소변경으로 연락이 되지 않으며, 대금결제 미해결로 연체자 및 신용불량자가 될수 있기 때문입니다. 

 


<출처: 삼성카드사>

Posted by 사용자 SB패밀리

댓글을 달아 주세요

자격증 vs 면허증

 

자격증은 사람이나 사물이 일정한 특성을 지니고 있음을 공식적으로 인정하거나 보장받는 것으로 등록이나 면허와는 차이가 있다. 특히 전문직의 법적 자격증은 그 자격증을 지닌 사람이 특정한 수준의 지식과 기술을 보유하고 있음을 보증하는 것으로 특별한 제한을 두고 있다.

 

면허증이 있는 분야의 경우, 없는 사람은 법적으로 그 일을 할 수 없으나, 자격증의 경우 그것이 없다고 해도 반드시 그 일을 법적으로 못한다는 것은 아니다. 일부의 경우 자격증 취득 후 해당 자격증에 따른 면허증을 별도로 발급받아야 업무 수행이 가능한 경우도 있다.

 

자격증은 거의 무자격자가 특정한 행위를 못하도록 제한하지는 않지만, 면허(license)는 제한을 가한다. 자격증은 흔히 등록(registration)보다는 통제가 강력하지만, 면허보다는 약한 것으로 인식되고 있다. 하지만 ‘자격이 있다’는 타이틀을 사용하지 못하게 법으로 제한을 한다. 전문가의 자격은 전문협회가 만들어져 자격에 필요한 정보나 인적교류를 하고 있다. 회비로 운영되며 회원들의 자격과 위상을 보증해 주고 있다.

 

 

 

면허

행정 기관이 어떤 사람에게 특정한 일이나 영업을 할 수 있도록 허가하는 문서

 

운전은 어디서 하든 면허 없이 하면 처벌받는다. 보건의료행위도 면허 없이, 누구에게 하든 면허가 없으면 처벌받는다. 원칙적으로 자기 스스로에게도 불법이다.

 

자격

각 분야에서 일정한 능력을 갖춘 사람에게 그 능력을 인정해 주는 증명서

 

자격증의 종류에는 크게 국가에서 발급하는 것과 민간에서 발급하는 것이 있으며, 국가에서 인정하는 자격으로 국가기술자격, 국가전문자격이 있으며 민간에서 발급하는 것은 민간자격증이라고 한다.

 

 

또, 대부분 국가에서 직접 실시하는 건 아니지만 민간업체, 혹은 공기업에서 실시하는 자격으로 법적으로 공인된 면허로 정부가 해당 면허에 대해 배타적인 권리를 부여했기 때문에 사실상 준한다고 해도 면허나 마찬가지이다. 예컨대 사서가 아닌 사람은 도서관 사서가 될 수 없고 변리사가 아니면 특허를 등록할 수 없으며 세무사가 아니면 기장대리를 할 수 없다.

 

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

부부관계 개선 방법

내가 사랑하는 사람이니깐 하면서 먼저 댓가없이 해주면 분위기가 현재의 딜레마를 깨서 한단계 업그레이드 됩니다. 근데 보통 이걸 못하죠 왜냐면 지 자존심과 지가 상대에게 먼저 해주는걸 싫어하고 댓가까지 바라거든요. 그래서 보편적인 초보부부들 삶이 딱 님네 집안과 같은 겁니다. 

그래서 남자 입장에선 "그래도 저 여자가 나 믿고 나한테 시집왔는데 내가 품어줘야지!" 라고 여자를 이끌어야 되고 여자는 "저 남자가 내가 뭐 그리 대단하다고 저렇게 나가서 돈 벌고 본인 자유 다 버리고 고생을 할까 밥이라도 잘 차려줘야지"라는 식으로 서로 접근을 해야 이게 시너지 효과가 팍!하면서 오르는 겁니다. 

대부분 부부사이가 안 좋은 집안 가보면 항상 시작과 과정이 똑 같습니다. 해주면 서로 손해보고 있다는 입장이거든요. 그러니 상대방보면 짜증부터 나는겁니다. 근데 부부사이가 좋은 집안가보면 뭐든지 자발적 입니다. 오히려 쉬라고 할정도로 내가 한다고 앞장서는 집안이지요. 
이러니 서로 신뢰가 쌓이고 서로 잘 할려고 하는 겁니다. 신뢰라는 건 이렇게 쌓이는 겁니다. 서로 잘 해 줄려고 하니 더 잘해 주고 싶은 겁니다.

근데 요즘(옛날옛적부터) 젊은 부부들 보면 대부분 자존심 싸움 뿐이에요. 누가 그러더군요. 

"사랑은 누구나 할 수 있다. 하지만 유지하는 건 아무도 가르쳐 주지 않는다."

이 글은 굉장히 심오하고 굉장한 해결사 노릇하는 키 역할을 하고 있는 내용입니다.

쉽게 읽고 넘기지 마시길.

Posted by 사용자 SB패밀리

댓글을 달아 주세요

귀여울때 깨물고 싶은 이유 





Q:귀여우면 왜 깨물어주고 싶을까요? 

  

A:동물의 본능적인 행동이다. 인간이 동물로서 하는 본능적인 행동에는 여러가지가 있다.

 예를 들어 식사, 잠 등과 같은 것이다. 

귀여워 깨물거나 안아주고 싶은 것은 인간의 호르몬 분비에 의한 기본적인 본능이 

최대한 절제된 상태로 표출되는 것이라고 할 수 있다. 

특히 깨물어주고 싶다는 표현은 먹는 본능과 관련지어 나타난다.

 주위의 애완동물이 자식을 핥는 행동을 보이는 것과 비슷한 현상이다. 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

만리장성 실제론 6750리 
 

Q : 만리장성은 실제로 만리일까요? 

 

출처 : 사진 상단에 표시



A : 시작하는 부분부터 끝나는 부분의 길이만 따진다면 2,700㎞로 6,750리가 된다. 그러나 만리장성은 시작부터 끝까지 한줄로 돼 있지 않다. 중간중간에 짧게 가지를 쳐 나가는 부분이 있다. 이 부분까지 다 계산한다면 6,400㎞가 돼 1만6,000리가 된다. 어떤 기준에 따르는가에 따라 실제 길이는 차이가 날 수 있다. 



<야후!코리아 지식검색팀> 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

[속보]조국 구속영장 기각.."구속 필요성 인정 안돼"

 

2019.12.27.01:00

권 부장판사는



"이 사건 범죄 혐의는 소명된다. 현 시점에서 증거를 인멸할 염려 있다고 보기 어렵다. 이 사건 범행은 그 죄질이 좋지 않으나, 구속 전 피의자 심문 당시 피의자의 진술 내용과 태도, 피의자의 배우자가 최근 다른 사건으로 구속되어 재판을 받고 있는 점 등과 피의자를 구속하여야 할 정도로 범죄의 중대성이 인정된다고 보기는 어려운 점, 피의자의 주거가 일정한 점 등을 종합해보면 도망할 염려가 있다고 볼 수도 없다"

Posted by 사용자 SB패밀리

댓글을 달아 주세요

[음식/요리] 안동찜닭 - 만원도 안든다

 

 

 

*재료 

닭(800g) 1마리, 당면 100g, 감자 2개, 양파 1개, 당근 ½개, 호박 ¼개

*조미료 

풋고추 3개, 대파 ½뿌리, 생강 1쪽, 식용유 2큰술, 물 1½컵, 참기름 1작은술, 소금·후춧가루 약간씩

*양념 간장 

간장 ⅓컵, 설탕·맛술 2큰술씩, 다진 마늘·참기름 1큰술씩, 후춧가루 약간



*이렇게 준비하세요

1 닭은 작게 토막을 낸 후 끓는 물에 살짝 데친다. 

2 감자와 양파, 당근은 큼직하게 썬다. 

3 풋고추와 대파는 어슷 썬다. 

4 호박은 반달 썰기 하고, 생강은 얇게 저민다. 당면은 미지근한 물에 담가 불린다. 

5 분량의 재료를 넣어 양념 간장을 만든다. 



*이렇게 만드세요

1 냄비에 식용유를 두르고 닭과 생강을 넣고 1~2분 정도 볶다가 양념장과 물을 붓는다. 

2 끓기 시작하면 감자와 당근, 마른 고추를 넣고 중불에서 끓인다. 

3 국물이 반으로 줄어들면 양파와 호박을 넣고 잠시 끓이다가 당면을 넣는다. 

4 당면이 투명한 색을 띠면 소금, 후춧가루로 간을 맞춘 후 불을 끄고 참기름을 넣는다. 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

사행습인운(思行習人運) 
 


 
생각이바뀌면 행동이바뀌고 
 
행동이바뀌면 습관이바뀌고 
 
습관이바뀌면 인격이바뀌고 
 
인격이바뀌면 운명이바뀐다 
 
———————————- 
 
변화는 작은 것부터 시작된다.

Posted by 사용자 SB패밀리

댓글을 달아 주세요

일상적으로 카페를 찾은 손님들은

남자와 소녀의 다툼 장면을 목격한다.

 

잠시 후 소녀는 화가나서 갑자기 염력을 사용하게 되고 

카페에 있던 사람들은 이 장면을 목격하게 된다.

 

 

 

 

 

 

https://www.youtube.com/watch?v=owe_aXsEBL8

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

핵전쟁이 일어났다.

우린 다 죽는다.

 

인터뷰 대상자는 인터뷰 도중 유리창으로 펼쳐진 시티뷰에서 핵폭탄이 떨어지는걸 목격한다.

 

LG전자는 LG 디스플레이 광고를 통해 그 생상함을 전하려 했다.

 

Experimenta la Ultra Realidad en nuestros nuevos LG UltraHD.

 

 

누구도 속고 만다.

 

 

 

Ultra Reality: What would you do in this situation? - LG Meteor Prank

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

NCS 직업기초능력, 직무능력평가요소

 

 
Posted by 사용자 SB패밀리

댓글을 달아 주세요

얼룩별 세탁법



페인트, 커피 자국 - 약간의 소다를 물에 타 희석액으로 살살 문지른다. (물과 소다의 비율 300배 정도, 아주 약간의 소다만 필요)



사이다, 콜라, 주스 - 엷은 소금물에 담가서 빨아준다.



맥주, 청주 - 물 또는 비눗물로 세탁하면 된다.시간이 지나 빼기 어려울 때는 알콜 1, 식초 1, 물 8의 비율로 섞은 물에 담가 빨고 물에 헹군다. 



간장, 혈액 (핏자국) - 무즙이 즉효. 자국이 묻은 곳에 묻혀 문지른다.



립스틱, 안주 - 버터를 얼룩 부위에 조금 바른 뒤 손으로 가볍게 문지른다. 그리고 남은 얼룩은 수건에 알콜을 묻혀 살살 두드리면 엷어진 립스틱의 기름기가 깨끗이 지워진다.



과일즙 - 식초 또는 암모니아수를 물에 희석해 닦아준 다음 빤다. 과일즙 얼룩은 제거가 쉽지 않으므로 바로 세탁하는 것이 좋다. 



매니큐어- 흔히 매니큐어 얼룩은 헝겊을 밑에 대고 아세톤으로 지우는데, 아세테이트나 테드론 천으로 된 옷에는 아세톤은 금물이다. 이럴땐 신나로 두드린 다음 물수건으로 닦아낸다.



카레 - 알코올을 흠뻑 적신 거즈로 두드린다. 



김치국물 - 양파로 즙을 내어 국물 묻은 자리의 안팎에다 바른 다음 하룻밤 지나서 물로 씻으면 감쪽같다. 


우유·아이스크림 - 거즈에 알코올을 적셔 뺀다음 비눗물로 닦는다. 뜨거운 물은 금물이다. 


껌 - 옷이나 카페트에 껌이 묻어 떨어지지 않을 때에는 흰설탕을 사용하면 된다. 껌 묻은 부분에 설탕을 한스푼 놓고 비비면 깨끗해진다. 오래되어 굳어버린 껌은 설탕을 놓고 그 위에 뜨거운 물을 조금 붓고 비빈다. 


파운데이션이나 크림얼룩 - 벤젠, 휘발유, 올리브 기름 등을 거즈에 적셔 두드리고 비눗물로 닦는다. 


볼펜 - 알코올을 적신 거즈로 얼룩진 부분을 두드리듯 닦아내거나, 알코올이 없을 때에는 물파스를 볼펜 자국이 난 곳에 두드려주면 지워진다. 


잉크 - 푸른 잉크나 검은 잉크의 경우에는 수산 50배액을 묻혀 두었다가 물수건으로 닦아낸다. 빨간 잉크인 경우에는 옥시풀 30배액으로 두드리듯 닦은 후 비눗물로 문질러 씻으면 깨끗하게 색이 빠진다. 


먹물 - 밥풀에 가루비누를 섞어 으깨어 얼룩진 부분에 문질러 발라두었다가, 그것이 마르기 시작하면 물로 비벼 빤다.



크레파스 - 흰종이를 얼룩의 아래위에 대고 다림질을 하면 기름기가 빠지므로 그런 다음 비눗물을 뺀다. 



유화물감 - 먼저 테레핀유로 닦고 다림질 해 말린 다음 신나로 두드리듯 닦아낸다. 


양초 - 흰종이를 얼룩의 아래위에 대고 다림질을 해 기름 성분을 뺀 뒤 비눗물로 씻어낸다. 



인주 - 벤젠으로 두드리듯 닦은다음 암모니아 20배액으로 씻은 뒤 반드시 물로 씻어낸다. 


녹물 - 세탁하기 전에 녹이 묻은 부분을 레몬조각으로 문지른다. 조금 놓아두면 얼룩이 엷어지므로 그 때 세탁하면 된다. 


진흙 - 옷이 마른다음 털어내면 되지만 그래도 얼룩이 남으면 붕산 50배액으로 두드려 뺀다. 



풀물 - 알코올로 닦기만 해도 대개는 지워지지만, 비눗물로 한번 더 닦아내면 완전해진다. 


담뱃진 - 신나 또는 알코올로 충분히 비벼서 물수건으로 닦아내면 된다.







그냥 지나치기 쉬운 세탁시 주의사항





여름철에 옷을 자주 빨면 안좋은 것으로 생각하는 주부들이 많다. 그러나 사실은 그렇지 않다.

옷을 오래 입거나 벗어둔 채 방치하면 땀의 암모니아나 염소 성분이 산화돼서 빨아도 때가 잘 없어지지 않는다.

이럴 경우 찌든 때를 없애려고 강력한 세제를 써 오히려 옷을 망가뜨리게 된다. 

손세탁한 고급 티셔츠가 상할 것을 우려해 대충 짜서 말릴 경우에는 남아있는 세제 때문에 얼룩이 생기고 고유의 색이 빠져나간다. 

헝겊으로 덮고 다림질해야 하는 옷을 그냥 다리면 옷이 번질거리며 변색된다. 최근 나오는 옷중에는 다림질 온도 대신 숫자만 표시된 경우가 많은데 1은 80~1백 20도,2는 1백40~1백60도,3은 1백80~2백10도가 적당하다는 표시다

Posted by 사용자 SB패밀리

댓글을 달아 주세요

고양이의   수명은?                
 
                
 

                
 
1살된 고양이는 
                15살의 청소년
 
                
수의학의 발달과 더불어 고양이에 대한 
                관심이 놓아져 각종 질병이 예방됨에 따라 고양이의 수명은 옛날보다 
                크게 연장되었습니다. 고양이의 평균 수명은 약 14년이며 태어난지 
                7년이 되면 노년기에 접어 듭니다. 
 고양이의 1살은 사람으로 
                치면 15세와 맞먹는 나이이고 2살은 사람의 24살에 해당됩니다. 
                
 
 
 
                 color="blue">고양이의 1년은 사람의 4년.
 
                6개월의 고양이은 10살의 어린이와 비교가 되며 태어난지 한 살된 
                고양이은 18세의 청년과 맞먹는 나이이고 두 살된 고양이는 사람으로 
                치면 24살에 해당됩니다. 두 살 이후에는 고양이도 조금씩 노화가 
                되니 1년마다 사람의 나이로 4년에 해당됩니다.
 
 
 
                 face="굴림" color="blue">고양이과 사람의 나이 비교표


            

출처 : https://m.blog.naver.com/PostView.nhn?blogId=yonggangah&logNo=220977120623&proxyReferer=https%3A%2F%2Fwww.google.com%2F


            

 

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 

 


                             size="1" style="color:black; background-color:black;">

                             face="굴림">고양이

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             style="background-color:rgb(255,246,220);">                             face="굴림">사람

                             face="굴림">고양이

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             face="굴림">사람


                             size="1" style="color:black; background-color:black;">

                             face="굴림">3개월

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             style="background-color:rgb(255,246,220);">                             face="굴림">5세

                             face="굴림">9년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             face="굴림">52세

                             face="굴림">6개월

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             style="background-color:rgb(255,246,220);">                             face="굴림">10세

                             face="굴림">10년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             face="굴림">56세

                             face="굴림">1년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             style="background-color:rgb(255,246,220);">                             face="굴림">15세

                             face="굴림">12년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             face="굴림">64세

                             face="굴림">2년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             style="background-color:rgb(255,246,220);">                             face="굴림">24세

                             face="굴림">16년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             face="굴림">72세

                             face="굴림">3년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             style="background-color:rgb(255,246,220);">                             face="굴림">28세

                             face="굴림">18년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             face="굴림">80세

                             face="굴림">4년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             style="background-color:rgb(255,246,220);">                             face="굴림">32세

                             face="굴림">20년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             face="굴림">96세

                             face="굴림">6년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             style="background-color:rgb(255,246,220);">                             face="굴림">40세

 

                             style="font-family:굴림,sans-serif; font-size:9pt;"> 

                             face="굴림">8년

                             style="font-family:굴림,sans-serif; font-size:9pt;">                             style="background-color:rgb(255,246,220);">                             face="굴림">48세

 

                             style="font-family:굴림,sans-serif; font-size:9pt;"> 


                             size="1" style="color:black; background-color:black;">


                

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

프로그래머의 발전 단계

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

프로젝트 조정자(Coordinator) vs 촉진자(Expeditor)

1 프로젝트 관리자의 역할 및 권한

 

* 프로젝트 조직구조에 따른 프로젝트 관리자(PM)의 역할 및 권한

  a 기능조직 : PM은 촉진자의 역할

  b 프로젝트 전담조직 : 가장 강력한 권한 위임

  c 약한 매트릭스 조직 : 기능조직+프로젝트 전담조직의 혼합형태. 기본적으로는 기능조직과 유사한 역할이지만 의사결정의 위임이 추가되면 조정자로 지칭

  d 강한 매트릭스 조직 : 프로젝트 조직과 유사한 PM 역할

 

2 구분

  a 프로젝트 촉진자(Project Expeditor) : 의사결정 권한이 없고 프로젝트 팀원들을 지원하며 팀원들의 의사소통을 조정하는 역할

  b 프로젝트 조정자(Project Coordinator) : 의사결정 권한이 있고 상위수준의 관리자에게 보고

 

 

 

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

라면은 중량에 비해 칼로리가 높은 편이나 비타민, 무기질, 식이섬유 등이 다른 식품에 비해 부족하다. 따라서 라면만 먹고 모든 영양소를 섭취한다는 것은 불가능하다. 



라면의 주성분인 밀가루는 우유, 쇠고기, 쌀에 비한다면 영양학적으로 완전한 식품이 아니다. 단백가가 낮아 인체의 단백질을 만드는 필수아미노산의 비율이 낮고 각종 아미노산이 고르게 들어 있지 않다. 

출처 인터넷



밀에 들어 있는 글루텐이라는 단백질은 소장 점막을 손상시켜 소화장애와 흡수장애를 일으킬수 있다. 주위에서 밀가루 음식을 소화시키지 못하는 사람은 소맥분을 소화시키는 효소가 결여돼 있는데다가 글루텐의 영향을 받기 때문이라고 볼수 있다. 

또 라면에 방부제를 첨가하지 않지만 수입한 밀가루 자체에 방부제가 포함돼 있을 가능성이 높은 것도 한 원인이다. 



라면은 또 스프에 2~3g의 염분이 들어 있기 때문에 하루 4g의 섭취권장량을 뛰어넘기 쉽다. 

아울러 기름에 튀겼기 때문에 생면이나 건면에 비해 배에 가까운 열량을 나타내므로 비만에 빠질 가능성이 더 높다. 

라면은 맛 좋고 값싼 기호식에 틀림없으나 자주 밤늦게 먹지 않도록 하고 야채 계란 김 등과 곁들여 먹는게 바람직하다. 

 

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

'Dark horse'는 우리가 흔히 '뜻밖의 유력한 경쟁상대'란 의미로 쓰고 있는 외래어입니다. 경마에서 'dark horse'는 '예상을 뒤엎고 우승하는 말'을 가리키며, 정치에선 출마 후보자로 지명이 되거나 선거에서 승리한 '무명인사'를 말합니다.



이 표현은 영국의 총리였던 Benjamin Disraeli가 1831년에 펴낸 'The Young Duke'라는 책에서 처음으로 썼다고 전해집니다. 이 책에는, 경마 대회에서 우승 후보인 말이 뒤처지고 생각지도 않았던 말이 어떻게 승리를 했는지 묘사되어 있습니다. 정치적 표현으로 'dark horse'가 처음 쓰인 것은 1844년 미국 민주당 전당대회이고 그 주역은 바로 James Knox Polk였습니다. 당시 그는 국가적 지도자라는 관점에서 무명인사였지만 민주당 후보 지명을 따내고 끝내는 대통령에 당선되었던 것입니다.



 

 

 

https://www.glassdoor.co.in/Photos/Dark-Horse-Development-Office-Photos-IMG2232403.htm

Posted by 사용자 SB패밀리

댓글을 달아 주세요

[문화/상식] "TGIF"란 일종의 인사라는데 무슨 뜻입니까?

 

Thanks God, it's Friday! (와, 신나는 주말이다!) 미국을 비롯한 많은 나라들이 주 5일 근무[수업]한다는 것은 모두 아는 사실이죠. 금요일이 주말이므로 TGIF는 주말을 축하하는 인사말입니다.





"OGIM"이란 표현도 있는데 이것은 "Oh God, it's Monday!"(괴로운 월요일이 돌아왔군!)이란 뜻입니다.

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

Hot dog라는 이름이 어떻게 생성되었는가에 관해서는 여러 이야기가 있습니다. 약 100년 전, 미국 도시에서 소시지를 요리해 파는 사람들이 따끈하다는 것을 강조하기 위해 "Hot! Hot!"하면서 호객을 했던 데에서 유래되어 그때부터 소시지는 hot으로 통하게 되었습니다.




그러다 장수들이 frankfurter라는 독일제 수입 소시지를 팔기 시작했습니다. 그 당시 'doggy'란 말이 유행했는데, 이 말은 '멋진'(fancy)이란 뜻이었습니다. 비싼 수입산 소시지가 예전 것보다 근사하다고 생각한 사람들은 frankfurter를 'doggy hots'라고 불렀고 이것이 나중에 'hot dog'가 된 것입니다.

 



또한, hot dog는 기쁨이나 놀라을 나타내는 감탄사로도 사용됩니다. "Hot dog!"하면 "야, 기분이다!", "신단다!"하는 뜻입니다.

 

 
Posted by 사용자 SB패밀리

댓글을 달아 주세요