2012-06-28 4 views
0

프로그래밍 언어 : java. 클래스 다이어그램에 문제가 있습니다.클래스 다이어그램 java 응용

브릿지 클래스는 다음과 같은 표현이 정확합니까?

내 관심사는 다음과 같은 선언을 처리하는 방법에 관한 것입니다. private 세마포어 세마포어; 나는 오른쪽 오전, 또한

--------------------- 
    Bridge 
    --------------------- 
    - semaphore: Semaphore 
    - lock: Lock 
    - waitingCond: Condition 
    - nNorthCars: int 
    - nSouthCars: int 
    --------------------- 
    + getIn(): void 
    + getOut(): void 
    --------------------- 

, 메인 함수 내부의 변수를 로컬되어 있다는 사실 주어진 :

public class Bridge { 
    private Semaphore semaphore; 
    private Lock lock: 
    private Condition waitingCond; 
    private int nNorthCars; ....... 
    public void getIn(int direction) throws InterruptedException{ 
    ..... 
The same goes for getOut().... 
} 

UML 표현 :

는 속성/메소드 선언입니다 그들은 사적으로 취급해야한다고 생각하니? (개인), + (공개)

는 어떤 도움을 매우 높이 평가 될 것이다 - 예를 들면 다음과 같습니다 :

--------------------- 
Main 
--------------------- 
- nThreads: int 
- time: long 
--------------------- 
+ main() 
--------------------- 

기호 :

public static void main(String[] args) { 
........... 
int nThreads = Integer.parseInt(args[0]); 
long time = 0; 
...} 

다음은 UML 구현입니다.

감사 일반적으로

답변

0

UML은 무신론자 구현/언어를 수하기위한 것입니다 -.은 UML 다이어그램을 읽을 때 당신이 알고 또는이 구현되어 어떤 언어 신경 안 또한, 클래스 다이어그램이 나타내는 의미 (또는 모델) 도메인 문제의 유형/클래스/개념과 그 관계. 따라서 메서드 내에서 지역 변수에 대해 걱정할 필요는 없습니다. 이는 구현 세부 사항이며 다른 클래스 또는 개념과의 관계와 관련이 없기 때문입니다.

UML을 사용하여 Java 프로그램을 모델링 (또는 리버스 엔지니어링)하고 클래스 다이어그램의 일부로 모든 변수를 프로그램에 포함하려는 것으로 보입니다. 이것은 당신이 취해야하는 접근 방식이 아닙니다.

SemaPhore, lockwaitingCondition 모든 구현 세부 사항이며, Bridge의 행동이나 Bridge '다른 클래스와의 관계에 대한 유용한 정보를 전달하지 않습니다. nNorthCarsnSouthCars은 비공개입니다. 모델에서 이러한 속성을 공개 속성으로 표시하는 것이 합리적입니까? 모델의 다른 클래스/개념이 이것에 대해 알아야합니까? 이 질문에 없다면 아마도 클래스 다이어그램에서 이것들을 삭제할 수도 있습니다. 아마도 액티비티 다이어그램에서 Bridge의 일부 메소드를 모델링하려고한다면이를 유지하고 싶을 것입니다. 다리는 아마 UML에서 다음과 같이하고 싶어이 그 관계는 다른 개념 외부에서 볼 수 있기 때문에 다리가, 뭔가 다른 (자동차의 아마 컬렉션) 다음 그 모델 수와 관계가있는 경우

--------------------- 
    Bridge 
    --------------------- 

    --------------------- 
    + getIn(): void 
    + getOut(): void 
    --------------------- 

당신의 모델.

Main은 프로그램 진입 점과 비슷하지만 다시 모델링 할 필요는 없습니다. Main이 다른 모든 (또는 대부분의) 클래스/개념을 모으면 다음과 같이 모델링하십시오. 그렇지 않으면 구현 세부 사항이됩니다.

마지막으로, UML은 실제로 코드에서 구현 한 개념을 모델링하기위한 것입니다.당신은 이것의 반대를하고있는 것으로 보입니다. 리버스 엔지니어링과 라운드 트립은 어느 정도까지는 괜찮지 만, 그렇지 않으면 UML을 해킹하고 코드를 생성하는 것에주의해야한다. UML의 개념은 도메인을 모델링하고 코드를 자르기 전에이 모델의 유효성을 검사하는 것입니다.

희망이 도움이 ...

관련 문제