개발::UDL

원본 : http://dreamfactory7.springnote.com/pages/2845690

 

20090320_객체통신.pptx

개발::UDL

편집하기

20090320_객체통신.pptx

개발은 크게 3단계로 나뉜다.
설계및 뼈대(인터페이스같은것) 만들기
외부판(View)만들기.
내부에 들어갈 살(Control)만들기.

 

 

자동차로따지면
1. 설계한다.
2. 프레임을 만든다.
3. 외장을 만든다.
4. 각부위를 연결시킨다.

규칙 :
- 1단계로갈수록 가장 범위가 넓다.
ex)4단계는 1단계의 범위를 넘어설수없다.
- 각단계마다 검증이 필요하다.

 

• 모듈화
  크게 MVC 형태로 나뉘고 각각은 전혀 연관성이없는 독립적인 객체이다. 이객체들은 상호간 통신을 통해 이패턴을 유지시킨다.

  • View : 화면부분으로 이부분만 플렉스, HTML기타의 규격에만맞는다면 어떠한 프로그래밍도 적용될수있다. 주로 마크업언어가 많이 쓰일것이다.

  • Control :

  • Model :

  • 연결자 : 각 모듈간의 통신을 가능하게하는 객체다.

   

 

차세대 언어는 모듈별로 가장최적화된언어가 쓰일것이다.
그중 View부분은 HTML(물론 지금보다 훨씬많이향상되어 gui의 모든 컨트롤을 표현가능할때 까지는되어야함)

을 비롯하여 각종 마크업랭귀지가 사용될것이다.

그리고 각모듈간에는 서로 규격된 통신을 사용할것이다.

Unified Digram Language (개인적으로 이것이 완성되면 uml의 다음버전으로 붙이고싶다...)
프로그래밍은 크게 3단계로 구분시킬수있다.
성능의 조절 - 컴파일러성능향상(효과 : 용량감소, 속도향상등)
표현언어 조절 - 코딩향상(효과:함축화(코딩한줄로 프로그램이 완성될정도의 효과) 체계화(C언어류), 등)
그리고 이를 상위에서 조절하는 IDE단에서는  더이상 의미를 두지않았다.

물론 IDE가 표현의 향상에 어느정도 도움이되었지만 그이상은 돕질못한다.

만약에. 가장 좋은 성능과 가장 좋은 표현을 서로 자신이 선택할수있다면 어떻게될까?
나라면
C언어만큼 강력한 시스템프로그램이되어야하고, 또한 인터넷프로그래밍까지 지원해야하고
표현언어형태로는 XML부터 SQL 등이 모두지원어야 가장좋은언어라고 생각한다.
당연히 나의 결론은 하나의 언어로서는 표현의 한계 성능의 한계가있다고 생각한다.

그럼 진정 그것을 하나로 합칠수없는걸까?
나는 그건 절때 아니라고 생각한다. 오히려 가능하다고생각한다.


예: 캐드
캐드로 설계를 할때 사람들은 선들의 조합으로 캐드를 한다. 그리고 가끔 렌더링이란것도한다.
만약 선그리는것과 렌더링이 프로그래밍에서 성능과 표현 볼수있다면

당연히 프로그래밍도 외부함수를 전혀쓰지않는 최하위 하드코딩부터 시작해서 완전 컴포넌트 조합까지
하나의 작업으로 가능할것이다.
왜냐면 캐드도 작도할때 선들의 조합을 컴포넌트처럼 저장시킬수있다고 들었기때문이다.
물론 이런 컴포넌트들이 엄청나게 늘어날때 그들의 관리도 소홀히할수없다.
그들만의 또다른 규칙과 질서가 필요한것이다.



예: 건축
다른표현으로하자면..
우린건축가다 흙으로는 어떤 집도 만들수있다.
그런데 큰제품을 만들기 힘들다 갈라지는 단점도있고 하중을 이겨야하는등 문제가많았다.
(초창기 기계어사용시..)

그래서 사람들은 벽돌이라는것을 만들었다.
집을 지을때는 적어도 벽돌이라는것을사용했을때 내구도와 모양을 개발자가 원하는대로 낼수있었다.

그런데 사람들의 요구가 다양해졌다.
어떤이는 고층집에살고싶어했고 어떤이는 보안이 철저한집을, 어떤이는 아름다운 집을,
또한 어떤이는 건강에 좋은 흙집을 원했다.

그렇다고 모두다 흙으로 지을순없는일이다.
결국 필요에따라 구조와 구성이 전부다른 건축방법을 선택했다.
고층집에서는 내구성이 있어야하므로 철제 구조물을 먼저 박고 그위에 건축물을 올렸고
보안이 철저한집은 내구성과 기밀유지를 위해 어느정도 복잡하고 견고하게 지었고
아름다운집은 예술양식을 적용해 아름다움을 부곽시키기위해 지었다.

그러나 결국 흙이라는 성분은 같다.
물론 세부적으로는 반드시 같은 흙은아니지만.
대체로 흙이라는 추상적인 개념은 동일하다.
다만 집의 형태에따라 철골이 들어가는가 들어가면 어떤철골이 들어가는가 등이 선택되졌다.


만약 프로그래밍에서도
하나의 흙처럼 하나의 표현언어로 시작하면안될까?
이언어는 모든 개발물(건축물)을 만들수있어야한다.
과연가능할까?

그러나 프로그래밍에서는 기존의 물건들을 무시한체 새로운것을 만들순없다.
그게 진짜 건축과 진짜개발의 차이점인것같다.


만약 추상적인개발만으로 개발이가능할까?
추상적으로 캐드처럼 작도만하면 그게 C 컴파일러로 컴파일되고
필요에따라서는 닷넷으로..
아니 이쯤되면 컴파일러가 뭐가되어도 상관없겠지.

모든 언어를 통합시킬 그런언어가 있어야한다.
그렇다고 또다른언어를 만들순없다.
그래서 나는 언어가아니라 언어와 매치가 가능하면서
어떤 개발자라도 쓸수있고 또 재사용이 가능한 것이 필요하다고생각했다.

새로운 개념이나 새로운 패러다임때문에 새로운 문법체계를 만들순없다.
그건 또다른 짐을 낳는격이다.
나는 흙을 그것도 아주고운흙을 주고싶다.
필요하면 벽돌로만들던지 아니면 돌로만들어서 사용하고싶은곳에 무엇과 섞에도 섞어져서 사용될수있게 하고싶다.


언어를 주무를수있는 언어.
그게 필요하다.
C에서 어셈블리를쓸수있고
닷넷에서 다른언어들을 호출할수있는것처럼..



뷰 :
- 화면구성
-- HTML같은 XML사용
- 스타일
-- CSS지원



컨트롤 :
최적화된 컨트롤들 설계로 만들수있다.
순서도로 만들수있다.


데이터 :
통합 데이터 연결시스템
모든 데이터에대한 공통사항을 사양화한다.


----------------------------
구태여 이런 뷰 부분을 프로그래밍화하는건 불필요하지않을까한다.
물론 다이너믹한 운영을위해서 필요는하겠지만.
우리의 기술중엔 외부 데이터와 연동해서 그데이터를 조작(manipulate)할수있는 충분한 기술들이있고
또 설령없더라도 그정도는 충분히 지원해줄수있을거라 생각한다.



- 만약 하위를 보고싶다면 공개된곳까지 추적하여 그하위의 내용을 볼수있어야한다.

- 필요하면 모든 외부 표현객체와 연동된다.
(CSS, 화면구성ML, 플래시같은 동영상 포멧등등.)




- C계열로 윈도우를 꾸미려는 얇팍한 생각은 버려라.
윈도우라하면 보여주어야하는데 그런 보여줌을 게을리한다면 콘솔이 더낫지않겠는가?


- 앞으로는 온라인이이곳 로칼이고 로칼이 곳 온라인이다.
그경계는 통신되고 안되고의 차이일뿐 그 뷰(표현)에있어서 온라인과 로칼의 차이는 없어질것이다.
CS처럼 보이는 온라인이 될것이다.
다만 지금처럼 CS를 따로받는일은없을것이고 사용자는 설치라는것을 느끼지못할정도로
사용하게될것이다.


- UDL은 생산속도는 늦지만 견고할것이고 체계적일것이다.

- UDL의 개발은 사용자 관점(엔드유저)에서 개발된다.
그리고 각 단계별 시점에따라 설계가 이루어지고 조립되어진다.
(
엔드유저 관점 : 그림그리는프로그램 필요(ui수준의 접근도 여기에 포함)
+1 : 기능들의 조립(최종 컴포넌트 단위 조립)
+2 : 각각 기능들의 구성(기본 컴포넌트 단위 조립)
+3 : 기능에따른 절차 구분 (이정도가 C레벨과같음)
+4 : 절차에따른 바이너리 최적화 ( 기계어수준)
화려한 ui에 강력한 기계어수준의 접근이 필요할경우
중간단계에서는 파이프(상하위 전달기능)만 넣어주면된다.
마치
5층에 사람이 주거하고 4, 3,2 층엔 아무것도안하고
1층에서 험한 일하는 그런 건물과같다.

이경우 이건물에 주거하는 사람은 험한일을 한다라는뜻이된다.

마찬가지로 5층에 사람이 살고(uI를지원)
4층에서 일하고 3,2,1층은 비어있다면
이건물은 5층과 4층만 쓰고 4층에 맞는 일을 한다.
프로그래밍으로 따지면 컴포넌트단위의 조립만으로 활용가능한 일을 하는것이다.

즉 각층별로 역할이 따로있다.
물론 5층까지만 예를 들었지만.
단계가 많을수있다.

- UDL은 어떤 프로그램과도 호환되어야한다.
다만 이에따른 원칙을 지켜야한다.
화면구성프로그램
레포트 프로그램
css
XML

UDL은 고무줄같은 C언어라고 생각하면되겠다.
타이트한 프로그래밍부터 컴포넌트 프로그래밍까지 모두 지원한다.

VIEW <-> (UDL) <-> 레포트

--------------------------------
UDL의 조립은 다음과같다.

- 절차 : 세부구현
- 조립 : 큰단위 구현
- 배치 : 조립품들을 배치하여 완성품으로만듬.

----------------------------
이것에대응하는 IDE는 프레임워크를 지원하는 마법사도 만들수있게 한다.

------------------------------
프로그래밍 공식

개발 : sdk(api가들어있는 라이브러리+ 컴파일러)+기타 도구
실행 : 런타임엔진

os는 이런 공식에 능동적이고 탄력적으로 대처될수있도록 설계되어져야한다.



UDL은 모든 외부 프로그램 또는 객체들에대해
공통적으로 컨트롤할수있는 인터페이스를 제공해야한다.
SQL, 리포트, 화면, XML등등..
관련내용상단에있음


----------------------------------------

----------------------------------------

외부객체
외부객체는 블랙박스가되어도상관없다.
다만 UDL에서 사용할수있도록 컨트롤 인자만 활성화되어있게만한다.
UDL은 객체를 주고받고만 할뿐
자체는 입출력자체가 전혀없는 언어다.
외부는 이렇게 연동제어로 활용한다.

- 뷰는 직접적으로 지원하지않는다.
다만 그 형식만 맞춰준다면 얼마든지 컨트롤가능하다.

외부객체는 단축의 형태로 UDL에서 사용가능하다.


flex 빌더에서 컴포넌트를 더블클릭하면 코드로 바로넘어오게하면좋겠다.
-----------------------------------------------
XML문서로
자동으로 위자드나 GUI로 매핑되는 데이터문서가필요함

--> HTML MXML과 다를게있나?

-------------------------------------------------
객체디자인
객체의 역할도 중요하지만
객체의 배치에따라 역할이 정해져버린다.
------------------------------------------------
UDL은 레벨에따른 시점을 균등하게 잡아야한다.
결국 보여지는것은 최종적인 면에서 2차원적인 형태이겠지만
레벨에따른 조합을 잘해야할것이다.

 

 

 

main()
{
    int a=0;
    while(1)
    {
        if(a==100)
        {
            printf("hellow world\n");
            break;
        }
        a++;
       
    }

}

<?xml xmlns:fn="." xmlns:io="stdio.h" >
<fn:main>
    <c:DECLARE name="a" type="int" />
    <c:while condition="true">
        <c:if condition="a==100">
            <io:printf parameter1="hellow world\n" />
            <c:break />
        </c:if>
        <c:OPERATION object="a" operator="++" />
    </c:while>
</fn:main>

페이지 히스토리

2009-03-27 20:32 에 우루사3호님이 마지막으로 수정