Verification & Validation Testing은 Verification과 Validation의 과정이라고도 할 수 있다. Verification과 Validation의 차이는 앞의 게시물인 Processs Activities에서 잠깐 다뤘었다. 간단하게 둘의 차이점에 대해서 설명을 하자면, Verification은 개발자 입장에서의 테스트이고, Validation은 유저 입장에서의 테스트이다. Static and Dynamic Verification Verification에는 두 가지 종류의 Verification이 존재한다. 하나는 Static, 다른 하나는 그 반대인 Dynamic이다. Static은 Software Inspections 라고 부르기도 하고, Dynamic은 Testin..

Design Patterns 디자인 패턴(Design Pattern)은 특정 문맥에서 반복해서 일어나는 문제에 대한 해결방안을 말하는 것이다. 특이한 문제에 대한 해결 방안이 아닌, 일반적인 문제에 대한 해결방안을 말한다. 일반적으로 잘 일어나는 특정 문제에 대해 사람들이 효과적이라고 인정한 그런 방법을 말한다. 이런 디자인 패턴은 만들어내는게 아니라 찾는 것이다. 가장 적절한 패턴을 찾아내는 것이 우리가 하는 일이고, 이를 찾는 가장 쉬운 방법은 아주 당연하게도 미리 알고 있는 것이다. 특정 문제의 솔루션에 대한 지식을 가지고 있으면 쉽게 해결 할 수 있다. Pattern Templates 대부분의 일반적인 문제를 해결하는 디자인 패턴들은 구글에 검색하면 쉽게 찾을 수 있다. 그리고 이를 쉽게 적용할 ..

Software Architecture 아키텍쳐(Architecture)라고 하면 전체적인 구조를 뜻한다. 하드웨어 아키텍쳐라고 하면 컴퓨터 구조, 하드웨어 구조를 말한다. 소프트웨어 아키텍쳐의 경우에는 큰 그림(big picture)으로 이해하면 쉽다. Big Picture 이 그림을 다시 한 번 보자. Process Activities 라는 글에서도 봤던 그림이다. ▼ 이 그림의 정체는 Android OS의 소프트웨어 아키텍쳐다. 위로 올라갈수록 소프트웨어 레벨이고, 아래로 내려갈수록 하드웨어 레벨이다. 즉, 우리가 흔히 말하는 High-level과 Low-level의 개념이다. 이렇게 위에서부터 아래까지 전체 서브 시스템들이 뭐가 있는 지 파악하기 쉽게 해주는 것이 소프트웨어 아키텍쳐이고, 전체적인..

Reuse in Object Orientation Object Orientation에서 재사용(reuse)의 핵심 컨셉은 캡슐화이다. Object Orientation에서는 모든 단위에 대해서 external interface를 제공한다. Component 단위에서도 내부가 아니라, 외부 인터페이스만 제공한다. 내부가 어떻게 동작하는 지 알 필요 없고, 시스템과 서브 시스템이 상호작용할 수 있게 정의된 인터페이스가 가장 중요하다. Component 그룹화된 독립적인 시스템을 Component 라고 한다. 인터페이스를 제공하는 것을 통해 자기 자신을 제외한 나머지와 사용할 수 있도록 해준다. 이를 Plugged Together 라고 한다. Plugged Together 같이 꽂는다라는 말로, 단순히 연결(..

State Machine 우리가 State Machine을 작성하는 최종 목표는 Event Action Table이다. Event는 특정 State에서 다른 State로 전환(Transition)을 일으키는 것을 말한다. 즉, Event Action Table은 특정 State에서 다른 State로 전환 될 때 발생하는 Action들을 모아놓은 것이다. Drawing State Machine 가장 위의 단계부터 그려보면서 내려가보자. Main Window & Alert Dialogue 기본 창과 알림을 보여주는 창과의 관계부터 시작된다.▼ 메인 화면(Main Window)에서 예산 확인 메뉴(Check Budget Menu)를 누르면 예산 확인 화면(Check Budget Window)으로 넘어간다. 그..

추후 이전에 작성했던 내용을 수정하여 올릴 예정입니다. 아래의 글이 영어긴 하지만 설명이 잘 되어있으니 참고하면 좋을것 같습니다. In UML class diagrams, what are Boundary Classes, Control Classes, and Entity Classes? I'm now using NetBeans as my IDE-of-choice, and it has a plugin for UML modeling. In the class diagram, there are model elements known as Boundary Class, Control Class, and Entity Class. However, I... stackoverflow.com

Detailed Design 앞에서 그린 Analysis 다이어그램만으로는 코드를 만들 수 없다. 그래서 아래의 것들이 있어야 코드로 표현할 수 있다. Types of attributes Operation signatures Assigning responsibilities as operations Additional classes to handle user interface 함수도 리턴 타입과 매개변수 타입을 정의해야한다. 이런 모든 것을 정하는게 Detailed Design이라고 한다. Class Specification : Atrributes 클래스의 Attribute를 표현할 때는 아래의 문법으로 표현한다. ▼ name ‘:’ type-expression ‘=’ initial-value ‘{’pro..

이전에 작성한 글을 수정하여 다시 올릴 예정입니다. 그동안에는 아래의 글에 설명이 잘 되어있는것 같아 아래의 글을 읽는것을 추천드립니다. 사실 제거 굳이 안보고 아래거 보는게 나을 거 같네요. 정리가 되게 잘 되어있어서 공부할 때 참고하기 좋았습니다. [ETC.] 시퀀스 다이어그램 작성법 & 예제 총정리 시퀀스 다이어그램이란? 시퀀스 다이어그램은 UML 다이어그램의 한 종류로 시스템이나 객체들이 메세지를 주고받으며 상호 작용하는 과정을 표현하는 행위 다이어그램입니다. 현재 구축되어 있 coding-factory.tistory.com

Use Case Realization Design 단계에서는 use case diagram그리는 것과 Step By Step Description을 만드는 작업까지 했다. 그러나 Use Case 만으로는 코드 만드는것을 할 수는 없다. 코드를 위한 최종 목표는 Class Diagram이며, 그 중에서 제일 중요한 것은 Public Function들이 정의되는 것이다. 이는 Communication Diagram을 통해 만들어지는 Design Class Diagram이 만들어지면 해결이 된다. 그런데 Use Case Diagram에서 바로 Class Diagram으로 바로 넘어갈 수 없다. Communication Diagram을 거쳐야 Class Diagram을 만들 수 있다. 커뮤니케이션 다이어그램까지..

Configuration management (CM) 변하는 소프트웨어를 관리하는 모든 프로세스와 툴을 CM이라고 한다. 파일을 사람이 직접 복사하고 옮기고 하는 걸로는 전체를 관리하기 힘들기에 소프트웨어를 관리하는 소프트웨어를 통하여 전체를 관리한다. System building 다 모아서 하나의 통합된 시스템을 만드는 것을 말한다. 모든 컴포넌트를 모아서 최종적인 바이너리 코드가 나오면 된다. Change management 버그 제거와 같은 요청들을 추적하고 관리한다. Release management 외부에다가 출시하는 것을 말한다. 버전이 여러개 나오는데 그걸 다 출시 하진 않고, 그 중에서 무엇을 출시 할 지를 정한다. 아래의 과정 전체가 CM이다. ▼ Multi-version systems ..