Software Engineering 7 - OOAD

Oop review
ADT(abstract data type) : data/operation을 하나의 문법적 요소(single syntactic unit) 안에 encapsulation 한 것.
class = ADT + inheritance + polymorphism
클라이언트의 코드는 매우 크기 때문에 왠만하면 수정하지 않도록 해야한다. 이럴 때 상기한 클래스의 특징을 통해 효율적으로 이를 설정하고, 외부 코드가 바뀌더라도 영향을 받지 않도록 해야 한다.

Inheritance
Y가 X를 상속할 때, X의 모든 데이터와 메시지를 Y 또한 받을 수 있으므로 Y is X 라 할 수 있다. (그러나 X는 Y가 아니다. 왜냐하면 Y가 더 추가한 것이 있을 수 있으므로) 따라서 X instance의 자리에 Y instance를 넣어도 사용할 수 있다.
polymorphism
같은 이름을 가진 다른 메서드가 존재할 수 있고, 어떤 객체가 그것을 호출하냐에 따라 다른 behavior를 나타낼 수 잇다. 따라서 if-else나 switch 문으로 객체를 판별하고 그에 맞는 함수를 써야하는 수고를 덜어준다.
- runtime polymorphism (dynamic polymorphism) : method overriding. 상속이 있을 때 부모자리에 자식 객체를 넣어 변화된 메서드를 호출하는 경우.
- compile time polymorphism(static polymorphism) : method overloading. 서로 다른 파라미터를 가지는 경우
Polymorphic variable
자신이 선언된 타입의 클래스 객체들 뿐 아니라, 해당 클래스를 상속하는 객체들도 가리킬 수 있는 변수. (일반적인 oop 변수) 만약 override 된 것들이 이 변수에 의해 호출되면, 런타임에 알맞은 메서드로 변형되어 호출된다.
abstract class : abstract method를 하나 이상 가지고 있으면 반드시 abstract class. 그러나 없어도 abstract로 선언하는 것도 가능.
여러 상속을 거치는 객체를 그 조상에 넣어 메서드를 실행할 때는 가장 먼저 해당 객체를 찾아보고, 그 다음은 바로 위, 또 그 위 를 반복하며 가장 낮은 자식에서부터 높은 조상까지 거꾸로 찾아가며 concrete method 가 존재하면 해당 메서드를 실행한다.
interface : public static final variable을 제외한 implementation, variable이 없고 오직 abstract 메서드만 존재하는 것. (implements를 통해 구현. 상속의 extends 처럼) 다른 클래스처럼 type(polymorphic variable)로 사용할 수 있다. (구현한 객체를 넣을 수 있음) 주로 객체 선언, 파라미터 전달 등에 사용하면 유연한 설계 가능.
일반적으로 "is a" 관계일 때 혹은 implementation을 제공해야 할 때를 제외하고는 abstract class보다 interface를 사용하는 것이 더 좋다. (왜냐하면 extends 와 implements는 동시에 사용할 수 있고 다른 것들에 비해 상위기 때문에 범용성이 높다.)
자바의 기본 타입은 모두 object를 상속하므로 범용적인 메서드는 이를 파라미터로 받는 것이 있다. 단, 상위로 올라갈 수록 아래에서 구현한 메서드는 사용할 수 없고 상위에서 선언한 메서드만 사용할 수 있기 때문에 기능이 한정된다. 따라서 범용성과 구현 사이를 적절히 판단해서 포인터 타입을 선언해야 한다.

클래스 간의 관계에 대해 화살표로 가리키고 있는 클래스(source, child)는 가리켜지는 클래스(target, parent)가 바뀔 때 영향을 받는다. 따라서 변화의 영향이 어디까지 미칠 지 클래스 다이어그램을 보고 판별할 수 있다. (일반적으로 association을 제외하고는 다 방향성이 있으므로 가위표/화살표를 안쳐도 된다. 일반적으로 상속과 포함 관계에서 whole은 part의 정보를 알고 있으므로. )
분석 단계에서는 의도적으로 정보를 누락시켜 아직 결정하지 못한 화살표를 표현할 수 있지만 설계 단계에서는 모든 화살표가 다 표현되어야 한다. 따라서 설계 단계에서도 화살표가 없다면 x가 쳐진 것으로 생각한다.
information hiding
앞서 말한 것 처럼 해당 인터페이스를 사용하는 클라이언트를 인터페이스의 구현의 변화에도 영향을 받지 않게 하는 것이 설계의 요지이다.

logical architecture
분석에서 설계로 넘어가는 과정. supplementary spec을 토대로 logical architecture (design model)을 만드는 것. 어떤 모듈, 패키지가 정의되는지 결정.
class들을 package, subsystem, layer로 구분하는 large scale organization. 각 원소들이 어떻게 deploy되는지는 아직 결정하지 않는다. (이는 deployment architecture에서 결정) package diagram을 통해 레이어, 유즈케이스, 클래스, 다른 패키지 등을 모두 나타낼 수 있다. (자바에서의 패키지, .NET과 동일)
- layer : cohesive(구별되는)  responsibility를 가지는 class/package, subsystem을 grouping 한 것. higher layer는 lower layer를 호출하여 사용할 수 있다. (반대는 불가. 하위일 수록 broad한 것을 가지고 있으므로 마치 상위가 하위를 상속하는 것과 같은 형태가 된다.) UI, application logic, domain object, technical service 등등의 layer로 구분된다.
strict layered architecture : 바로 밑에 있는 레이어만 사용할 수 있는 것. network protocol에서 자주 사용되며 information system에서는 사용되지 않는다.
relaxed layered architecture : 위와 반대로 여러 단계 밑에 있는 레이어도 호출할 수 있는 것. (bypass하여 하위를 direct call)
관심사(concern), low/high level, application specific한 것들을 모두 분리하여 관리할 수 있게 해주는 것이 layer를 사용할 때의 장점이다. coupling, dependency를 줄이고 cohesion을 늘려 usabiltiy를  증가시킬 수 있다.

software architecture : 소프트웨어의 가장 원천적인 구조와 이들을 생성하는 규칙이다. (소프트웨어의 앞으로 발전에서 변화를 결정하는 근본) 각 structure는 software element와 relation으로 구성되고, 이들의 property가 포함된다.
package dependency : 큰 패키지 사이의 관계를 클래스 다이어그램과 동일한 방식으로 표현.
Domain layer & Domain Objects
application logic을 객체들을 가지고 디자인. 이는 해당 개념들을 real-world domain에서 가져와서 도메인 오브젝트를 만드는 것으로 가능하다.
따라서 problem domain space를 나타내는 것을 domain object라 하고, 이는 related application, business logic을 가진다. 그리고 이들과 logic을 포함하여 관리하는 것이 domain layer가 된다.
앞서 배웠듯이 분석단계의 도메인 모델은 현실을 반영하여 만들어지므로 이를 가져와 설계 단계에서 사용할 때는 우리가 만드는 소프트웨어와 현실 사이의 괴리를 줄이는데 기여한다. (representation gap)

partition : 수직적으로 나누는 layer와 달리, 한 분야 내에서 각각을 다시 수평적으로 나누는 것을 의미.
tier : logic구조와 physical 구조를 매핑 시켜주는 것. (일반적으로 LA에서는 사용안함)

Model - View separation
자주 변하는 UI object와 non-UI object를 직접적으로 연결되는 것은 좋지 않다. (non-ui object가 UI를 직접적으로 호출하거나 알게되면, UI가 바뀔 때 마다 연결된 모든 non-ui object를 고쳐야 한다) 또한 application logic을 UI object method에 구현하지 않아야 한다.
View - UI layer / Model - Domain layer. 이 둘을 분리하여 설계해야 한다.