본문 바로가기

소프트웨어공학115

소프트웨어 아키텍처(Software Architecture) ISO/IEC 42010(IEEE 1471) I. 소프트웨어 컴포넌트간의 상호관계 및 구조, 소프트웨어 아키텍처의 개요 가. 소프트웨어 아키텍처(Software Architecture)의 정의 - 소프트웨어를 구성하는 컴포넌트와 컴포넌트의 관계를 추상적인 수준에서 정의하여 시스템 설계와 개발 시 적용되는 원칙과 지침을 제공하는 시스템 구조 나. 소프트웨어 아키텍처의 등장배경 다. 소프트웨어 아키텍처의 특징 - 소프트웨어 시스템의 구조 결정 - 여러 소프트웨어 요소 또는 컴포넌트로 구성 - 요소, 컴포넌트는 외부로 드러나는 속성, 즉 인터페이스를 갖는다. - 요소, 컴포넌트 간 서로 관계를 가지며 인터페이스를 통해 통신한다. - 요소, 컴포넌트를 설계하고 변경하는 것에 대한 원리, 가이드라인 제공 II. .. 2021. 1. 31.
SPEM (Software Process Engineering Metamodel) Metamodel I. 소프트웨어 개발 프로세스의 메타모델, SPEM의 개요 가. SPEM (Software Process Engineering Metamodel)의 정의 - 소프트웨어 개발 프로세스와 그에 관련된 사항 (용어, 개념, 관계)등을 정의하기 위해 OMG에서 개발한 메타모델 나. SPEM의 특징 - 메소드 정의와 정의된 메소드의 개발 프로세스 적용 간의 명확한 분리 - 다양한 개발 프로세스의 일관된 유지보수와 다양한 생명주기 모형의 반영 - 유연한 프로세스 가변성과 확장성 플러그인 매커니즘 - 신속한 프로세스 조립을 위한 베스트 프랙티스의 재사용 가능한 프로세스 패턴 II. SPEM의 아키텍처 및 구성 가. SPEM의 아키텍처 나. SPEM의 구성 패키지 구성 내용 Core SPEM 메타모델.. 2021. 1. 31.
시퀀스 다이어그램 (Sequence Diagram) 시간적 개념, 액터, 활성객체, 메시지, 제어사각형 I. 시간의 흐름에 따른 표현, 시퀀스 다이어그램의 개요 가. 시퀀스 다이어그램 (Sequence Diagram)의 정의 - 문제 해결에 필요한 객체 정의, 객체간 송/수신 메시지의 순서를 시간의 흐름에 따라 표시하는 다이어그램 나. 시퀀스 다이어그램의 특징 시간적 개념 객체간 동적 상호작용을 시간적 개념을 중시하는 모델링 협력사항 여러 객체들 사이의 동적인 협력사항 (Collaboration)을 표현 무관계성 객체들 간 관계성은 표현 안함 순서적 표현 복잡한 시나리오, 실시간 명세표현, 메시지의 명시적 순서를 나타내기 용이 II. 시퀀스 다이어그램의 구성요소 및 메시지 종류 가. 시퀀스 다이어그램의 구성요소 구성요소 표현법 설명 액터 (Actor) -.. 2021. 1. 31.
액티비티 다이어그램 (Activity Diagram) 작업흐름, 활동, 시작/종료, 판단, 전이, 동시성, 구획면 I. 비즈니스 작업 흐름 표현, 액티비티 다이어그램 개요 가. 액티비티 다이어그램 (Activity Diagram)의 정의 - 사건의 발생에 관련된 객체들의 상호 관계를 각종 처리 로직이나 조건을 순서에 따라 도식화한 다이어그램 나. 액티비티 다이어그램의 작성목적 처리순서 표현 대상에 상관없이 로직과 처리 순서를 표현하기 위해 작성 비즈니스 프로세스 정의 시스템화 대상화 영역에 속한 현재 업무 분야의 비즈니스 처리 흐름을 표현 처리 흐름의 도식화 프로그램 처리 흐름을 도식화하여 간단하고 명료하게 처리 로직을 표현 II. 액티비티 다이어그램의 구성요소 구성요소 설명 표기법 Activity state/ Activity (활동) 행위나 작업 (내부적.. 2021. 1. 31.
클래스 다이어그램 (Class Diagram) 객체, Private, Public, Protected, Attribute, Operation I. 객체 타입을 정의하고 정적인 관계를 표현, 클래스 다이어그램의 개요 가. 클래스 다이어그램 (Class Diagram)의 정의 - 시스템에서 사용되는 객체 타입을 정의하고 그들간의 존재하는 정적인 관계를 다양한 방식으로 표현한 다이어그램 나. 클래스 다이어그램의 특징 객체 관계 표현 Class, Interface, Collaboration (협력) 관계 표현 정적 구조 표현 구현 시스템 내 Class 들간의 정적 구조 표현 코드 변환 다이어그램 작성 후 즉시 코드 변환 가능 II. 클래스 다이어그램의 구성 및 관계표현 가. 클래스 다이어그램의 구성 나. 클래스 다이어그램의 관계표현 관계유형 표기법 설명 연.. 2021. 1. 31.
UML 2.0 Composite Structure, Package, Interaction Overview, Timing I. 수준 높은 자동화를 지원하는 UML의 진화, UML 2.0의 개요 가. UML 2.0의 정의 - 웹 기반 어플리케이션과 SOA등 신기술의 등장으로 수준 높은 자동화를 지원하는 UML 기반의 도구의 필요성이 증가함에 따라 원래 표준보다 더 명확한 방식으로 UML 정의 나. UML 2.0의 등장배경 한계 내용 복잡성 크고 복잡하여 배우기 어려움, 적용이나 구현을 위한 접근이 어려움 이해하기 어려움 UML 규격의 Sematics나 Notation의 상세 내용에 대해 이를 정확하게 이해하기 어려움 간결성 부족 언어의 간결성 부족 서로 다른 도메인과 서로 다른 플랫폼에 효과적 대처 어려움 모델 공유 어려.. 2021. 1. 31.
UML(Unified Modeling Language) 객체지향 분석, 설계, Use-case, Class, Sequence, Activity I. 객체지향 분석, 설계를 위한 모델링 언어, UML의 개요 가. UML(Unified Modeling Language)의 정의 - 객체지향 분석과 설계를 하기 위한 모델링 언어로 OMG(Object Management Group)에서 모델링 기술과, 방법론을 표준화한 언어 나. UML의 특징 특징 내용 가시화 언어 프로젝트 계획, 실행, 변경 통제 문서화 언어 요구사항관리, 범위 정의, 산출물, 베이스라인 관리 구현 언어 WBS 승인, 일정 수행 및 평가 조정 명세화 언어 프로젝트 활동 완료를 위한 모든 비용, 예산 관리 II. UML의 구조 및 모델 가. UML의 구조 구성요소 내용 Things 모델에서 주제를 .. 2021. 1. 31.
다형성 (Polymorphism) Over-loading, Over-riding I. 동일한 이름의 메소드를 테일러링 하는 개념, 다형성의 개요 가. 다형성 (Polymorphism)의 정의 - 여러가지 형태를 받아들일 수 있는 특징으로 동일한 이름의 메소드를 다른 객체 또는 서브클래스에 호출할 수 있는 특징 나. 다형성의 특징 - 동적바인딩, 확장성 지원, 재사용성 지원 다. 다형성의 종류 오버로딩 (Over-loading) 클래스 내에서 동일 명의 메소드를 매개변수나 타입을 변경하여 재정의 오버라이딩 (Over-riding) 하위 클래스에서 상위 클래스에서 상속받은 메소드의 내용을 재정의 II. 오버로딩, 오버라이딩의 개념도 및 비교 가. 오버로딩, 오버라이딩의 개념도 - 동일한 인터페이스를 갖는 객체들이 그 동작은 완전히 다를 수 .. 2021. 1. 31.
객체지향 (Object-Oriented) Entity, Attribute, Method, 캡추다정상 I. 현실세계의 객체 표현한 개발 방법, 객체지향의 개요 가. 객체지향 (Object-Oriented)의 정의 - 현실세계에 존재하는 객체(Entity)를 속성(Attribute)와 메소드(Method)가 결합된 형태의 객체(Object)로 표현하는 개념 II. 객체지향의 구성도 및 구성요소 가. 객체지향의 구성도 나. 객체지향의 구성요소 구분 설명 객체 (Object) - 문제 영역에서 잘 정의된 역할을 가지고 각각 구분할 수 있는 단위, 개체, 품목을 의미하는 것으로 데이터와 함수로 구성 클래스 (Class) - 하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 데이터 추사화를 의미 - 객체를 생성 할 수 있는 구조와 정보를 가지고 있는.. 2021. 1. 31.
객체지향 설계원칙 SOLID I. 유지보수와 확장이 쉬운 시스템 설계, 객체지향 설계원칙의 개요 가. 객체지향 설계원칙의 정의 - 로버트 마틴에 의해 명명된 객체지향 프로그래밍의 설계의 5가지 원칙으로 시간이 지나도 유지보수와 확장이 쉬운 시스템 구축 원칙 나. 객체지향 5가지 설계원칙 항목 - SRP, OCP, LSP, ISP, DIP II. 객체지향의 5가지 설계원칙 (SOLID원칙) 원칙 구분 설명 SRP 명칭 단일 책임의 원칙 (Single Responsibility Principle) 정의 하나의 클래스는 하나의 책임만을 가져야 한다 개념도 - 하나의 책임만 가지고 있는 클래스로 세분화하여 생성 OCP 명칭 개방 폐쇠의 원칙 (Open Close Principle) 정의 상하 관계인 확장은 열려 있고 수평 관계인.. 2021. 1. 31.
반응형

티스토리툴바