LIPNUS

상속: 이렇게 하면 Queue를 List대신 쓸수는 없음 -> 치환원리 좆망 Composition : 낫배드 C타입을 걍 넣어봤더니 ㅈ됨 / LSP극복하려고 Exception으로 극복하니 더 ㅈ됨

Abstract Data Type - 하나의 문법적 요소 - Encapsulation Runtime - 오버라이딩 Compiletime - 오버로딩 X a = new X(); X b = new Y(); 자손의 객체도 가리킬 수 있다. b.method() 하면 X가 아니라 Y에 있는 매소드가 실행됨. Y c = new X(); (ㄴㄴ) 하나이상의 abstract 매소드가 있으면 abstract클래스여야만 함 abstarct클래스여도 abstract 매소드가 없어도 됨 폴리몰피즘 룰이 동작하므로, 자손의 instance를 가리킬 수 있음. X a = new Y(); a.method(); method가 Y에 없으면 X에 있는거 실행 아예 없으면 컴파일에러 인터페이스는 모든 매소드가 abstract (absta..

Parameter를 Attribute로 바꾸는건 쉬움 매개변수로 받은거 최상단에 선언한 변수에 할당하면 되니까. Class Diagram에서 스켈레톤코드 바디는 Sequence Diagram콜 관계를 보고 채워넣음

Visibility : Class Diagram, Code작성 단계를 통해 조절 받은거 Attrivute에 할당해서 쓰면 Parameter visivility가 Attribute Visibility로 바뀜 클래스다이어그램으로 클래스 정의하고 Interaction다이어그램, Sequence Diagram으로 Method의 body를 채움 Class를 구현할때 dependency가 없는 것부터 구현 그리고 거기서부터 챡챡

지금은 Logical이고 패키지다이어그램으로 한다. 로지컬 아키텍쳐의 대표주자는 Layered Architecture. Operation이 걍 들어오는게 아니라 UI를 통해서 들어오는 거였고, Package Diagram으로 그걸 표현할 수 있다. Object Diagram은 static에 약간더 가까움

① 이건 Elaboration에서! ③ Elaboration에서 최종적으로 fix하며 해결, Inception에서는 찾기. 찾는다까지는 맞음 ③ 기능요구사항도 크게 영향을 미치는데, 비기능요구사항도 영항을 미친다. 기능요구사항은 충족이 안되면 아예 시스템출시불가. 비기능이 삐꾸면 돌아는 가는데 여러 문제들이 발생. system operation이 외부 Actor들에게는 interface이다 r은 없지만, Brief -> Casual -> Full 은 진행됨 .Usecase 자체는 변하지 않기때문에 r은 아님. Elaboration단계 중간에서 Operation contracts만들면 안됨. 계속 바뀌니까. 그래서 이건 Elaboration이 끝나는 시점에서 만들어야 한다. Construction 에서도 ..

[UML] 클래스 다이어그램 이해하기 [UML] 클래스 다이어그램 이해하기 [UML] 시퀀스 다이어그램 이해하기 안녕하세요. 오늘은 클래스 다이어그램에 대해서 이야기 해보고자 합니다. 최근 레거시 시스템의 구조개선을 조금씩 하고 있 sabarada.tistory.com [UML] 클래스 다이어그램 작성법 - Heee's Development Blog Step by step goes a long way. gmlwjd9405.github.io

skillfully? : - customer랑 같이 - workshop - demo - Functional Requirement - Non Functional Requirement : Git, 문서화, IDE, 규약 뭐 이런 것들

UP : unified process s : start r: requirement 수정가능

③ Activity Diagram은 Optional한 Diamgram임 ④ Activity Chart는 Flat하게만 쓴다. ⑤ 상호작용은 Class Diagram 개발초기에는 안나오고, 개발 후반부에 등장 component : 독립적인 개발의 단위 Webstore, Warehouses, Accounting을 3개 팀에서 만들 수 있음 Component Diagram, Composit Structure Diagram 별로 구분없이 쓴다. 외부랑 연결된건 Delegate Connector, 내부 컴포넌트 끼리 연결하는건 Assembly connector 라고 함

Statechart diagram은 activity diagram이랑 비슷. 둘중에 하나만 그림. 서로 그리는 방식이 반대라서. 저장된 H없으면 그냥 화살표 쭉 지나감

대각선 : call하는데도 시간이 걸린다

Usecase가 중요한거지, Usecase Diagram이 중요한게 아님. 텍스트가 중요. OOAD뿐만 아니라, SASD에서도 씀. OOAD에서는 무조건 씀. (Usecase = Functional Requirement) 텍스트가 찐이고, Usecase Diagram은 그림으로 정리해둔것. System의 Boundary도 표현할 수 있음.

Diagram : 이탤릭체는 Abstract 클래스. (Interaction Diagram도) 네모 튀어나온거는 패키지 대문자 : 클래스 소문자 : object 여기부터는 Behavior Diagram

*Risk를 해결하면서 돌아야 함. Client-driven/Architecture 두가지 Risk를 고려하면서. elaboration에서 architecture는 정해짐.