Software Engineering 1 - Basic Models & UML

소프트웨어 공학은 '무엇'보다 그것이 '어떻게' 만들어지는지에 중점을 둔다.
 

brook's law : 작업자 간의 interaction이 필요한 일의 경우, communication의 overhead가 발생하기 때문에 일정이상 리소스를 투입할 경우 더 느려지는 경우가 발생할 수 있다.
 

- model = Abstraction of the system

software Architecture : software를 구성하는 여러 component의 layer와 interaction을 표현하는 Big Picture. performance, reliability 등 software의 중요 품질 속성들은 결정한 이후에 수정하기가 어려우므로 이들을 중점적으로 달성하기 위해 구성해야 할 구조 및 메커니즘을 나타내는 것.


project는 몇 개의 activity로 구성되며, activity는 몇 개의 task로 구성된다. 각 task는 work resource를 소모하여 work product를 만들어 낸다. 이 때 resource는 시간이나 장비 등이 해당되며, product는 system, model, document 등이 해당된다.

Software Development Process (= Software Development Life Cycle)
activities in software development : requirement elicitation(추출) - analysis - system design(아키텍처) - detailed design(object design) - implementation - testing
각 단계에서 생성되는 product는 use case model- application domain object- subsystem - solution domain object - source code - test case 가 된다.

Software Development Process Model : 위의 프로세스를 특정 관점(상황)에 맞게 추상화시켜 나타낸 모델.
-순차적 모델 : waterfall, v- model
-iterative 모델 : spiral model, unified process(RUP)

plan-driven process : 모든 계획을 먼저 세워 각 과정을 계획과 비교하여 평가
agile process : 계획을 점진적으로 생성, 변화에 유동적으로 대응
모델 및 프로세스에는 정답이 없으며 알맞은 상황에 따라 유동적으로 사용 가능하다. 또한 모든 프로젝트의 진행은 딱 떨어지는 것이 아니라 각 부분의 일면을 모두 가지고 있는 것이 더 효율적이다.

1. Waterfall model(1970)
Requirement analysis - Design - Implementation - Testing - Maintenance 의 주된 activity(phase)를 규정함. 각 phase는 이전 phase가 완벽히 끝나고 검증된 이후에만 실행 가능하다. 각 단계는 모두 한 번만 수행하지만 잘못되었을 경우 이전 단계를 수정하는 loop-back이 가능하다.
간단하고 문제를 명확하게 정의하며 관리자의 입장에서 관리하기가 편하다. 대규모 이거나(문서 위주의 일이 필요) 주로 변하지 않는 requirement에 대해 프로그램을 제작할 때 많이 사용된다. 그러나 requirement가 개발 초기 단계에 fix되지 않고 기술의 발전을 고려하지 않는다는 단점이 있다.
2. V-model
위의 폭포수 모형에 변형을 가한 것. Testing 단계를 오브젝트, 통합, 시스템으로 나누어 디자인 결과를 한단계식 올라가며 검증하는 방식을 사용한다. 따라서 각 단계를 시행할 때 검증 case도 함께 제작한다. 이를 통해 각 단계를 더 엄중하게 검증할 수 있다.
하드웨어와 연관되거나 자동차 등과 같이 안전에 직결되어 검증이 필요한 경우에 많이 사용한다. 그러나 여전히 경직된 단계를 가지고 있다는 단점을 가지고 있다.


* 요구사항 변경에 대처하기 위한 방법
1) prototype - quick & dirty.
중요한 key feature만 포함하는 prototype을 제작하여 feedback을 받을 수 있다. 이런 프로토타입을 만들 때는 세부사항을 조율하거나 겉모습에 신경쓰지 않고 기능만 구현하여 빠르고 지저분하게 제작하는 것이 중요하다.
이를 통해 requirement를 더 확실하고 안정적으로 고정시킬 수 있고 해당 개발의 경험을 사용할 수 있다. 그러나 코스트가 더 필요하다는 단점이 있다.
2) iterative & incremental development
한 번에 프로그램을 만들지 않고 점진적으로 프로그램을 제작하여 고객과 협의하고 요구사항을 확인하는 방법. agile 및 rup 등 비교적 최근 방법이 많이 선택하는 방법.
가장 risk가 크고 중요한 것 부터 개발하여 확인 받고 요구사항을 확실시 할 수 있다. 중간에 변경이 발생하더라도 중간 단계의 반복에서 이를 수정할 수 있다. 따라서 위험이 감소하고 효율적인 피드백을 받을 수 있으며 변경이 유연하게 가능하다.
대부분 현재에 제작되어 제공되는 앱 등이 이런 방식을 채택하여 고객의 피드백을 수용하는 방식을 채택하고 있다. 그러나 반복적 작업이 필요하므로 비용이 더 커질 수 있고, 애초에 제작한 아키텍처와 디자인이 가장 효율적이지 않을 수 있다.


3. Spiral model(1986)
Objective setting(목표 식별, constraint 확인) - Risk assessment & reduction - Development & validation - planning의 sector를 반복적으로 실행한다. 따라서 fixed phase가 존재하지 않음.
유연하게 반복적 개발과 위험관리를 할 수 있는 모델.

4. Rational Unified Process (RUP) & Unified Process (UP)
Iterative, Architecture-centric, use-case driven 이라는 특징을 가지고 있음. UML을 사용하여 나타낸 것을 프로그래밍 적으로 구현할 때 사용하는 것이 UP. RUP는 어떤 회사가 만들어낸 UP의 확장 버전.
UP의 Phase : Inception(범위와 효용을 확인) - Elaboration(risk 감소, stable한 architecture) - Construction - Transition.
waterfall과 비슷해보이지만 해당 phase를 반복적으로 수행하여 위험을 식별하고 관리한다는 점에서 완전히 다르다. 각 단계에서는 오직 그 단계만 수행하는 것이 아니라 해당 제목이 가장 큰 부분을 차지하며, 다른 파트도 약간씩 존재한다.
폭포수모델과 달리 반복적 개발로 인한 milestone이 있고, risk 관리를 하는 단계가 따로 있기 때문에 위험관리에 있어 매우 효과적이다.

UML = Structure Diagram + Behavior Diagram + Interaction Diagram(behavior의 subset), 구조와 행위에 대한 것으로 나눌 수 있음.
Model = Abstraction of the system. 크고 복잡한 문제를 분해하여 핵심적인 내용만 확인하기 위한 작업. 시스템의 특성에 맞고 활용할 수 있는 다이어그램을 취사선택하여 사용.
1. Use-Case Diagram : 시스템의 기능을 표현. 액터와 상호작용 가능한 유즈케이스(기능), 그리고 그들 간의 dependency를 나타내는 그림.
2. Class Diagram & Object diagram : 시스템의 정적 구조를 나타내는 것을 각 객체와 클래스 간의 상속관계와 연관관계를 나타냄. 이런 클래스의 인스턴스를 나타내는 것은 오브젝트 다이어 그램이 된다.
3. Activity Diagram : flow chart와 같은 맥락으로 workflow를 표현하는 그림.
4. State Diagram : 위와 비슷하지만 대상이 하나의 오브젝트로 제한되며, 제한된 state를 가지고 있다. 따라서 해당 오브젝트의 dynamic behavior(외부 작용에 따라 내부 state가 어떻게 변화하는지) 를 나타내는 것이 목적이다.
5. Sequence Diagram : 외부 액터와 시스템 혹은 시스템의 오브젝트들 끼리 상호작용하는 dynamic behavior를 보여준다.

- Class & Object Diagram
Object : system의 individuals. 특정 클래스의 instance인 object name과 class name, 해당 오브젝트의 attribute와 current value를 사각형에 담아 나타낸다. 이름이나 클래스는 둘 중 하나 이상만 표현하면 된다.
object diagram(instance diagram) : 특정 순간(snapshot)에 여러 오브젝트들 사이의 관계를 나타내는 그림. 따라서 시간의 흐름에 따라 이 관계가 변화할 수 있다.
class와 object 사이 관계는 객지프에서 배운 것과 동일하다. Attribute는 class의 structural characteristics이며 각 객체마다 서로 다르게 가진다. 그러나 operation은 class의 behavior로써 모든 클래스가 동일하게 가지므로 object diagram에 표기되지 않고 class diagram에 표기한다.
Class Diagram = Class name + Attributes + Operation으로 구성된다. 그리고 여기에 더해 static 한 variable들은 class가 공통으로 가지는 속성(하나만 존재, 모든 instance가 공유)이므로 이를 class variable(class attribute, static attribute) 라고 하여 따로 추가한다. operation도 마찬가지로 static operation을 따로 정의하여 객체가 없을 때도 사용할 수 있게 만들 수 있다. 이 static attribute & operation은 밑줄을 그어 일반 attribute & operation과 구별한다.
또한 diagram의 내부에서 + 는 public, -는 private, #은 protected를 의미한다.

Abstract Operation & Class( <-> concrete class)
instance를 만들 수 없는 abstract class도 나타낼 수 있다. Abstract operation을 하나라도 가지고 있는 class는 반드시 abstract class이며, abstract operation이 없더라도 abstract class로 선언될 수 있다.
Abstract class는 이름을 이탤릭체(기울임)로 쓰거나, <<abstract>>로 prototyping 하거나, {abstract} property를 주면 된다. abstract operation의 경우, 이탤릭체로 쓰거나 {abstract} property를 주면 된다.


Interface : public abstract operation만 선언한 집합체.
component가 interface를 구현하는지, 필요로 하는지에 따라 두 가지로 서로 다르게 표현된다.
- Provided interface : 특정 interface를 다른 component가 구현할 경우 ball(lollipop)으로 연결되거나 <<interface>>를 사용하고 상속자와 구현 연결로 표현한다.
- Required interfaces : 어떤 component가 작동하기 위해서 interface를 공급받아야 하는 경우를 나타냄. 이 떄는 소켓(반원)이나 ball symbol이나 stereotyped class icon에  dependency arrow를 연결하여 나타낸다.