OOAD-퀵 가이드

짧은 역사

객체 지향 패러다임은 새로운 프로그래밍 접근 방식의 초기 개념에서 형태를 띠고 설계 및 분석 방법에 대한 관심은 훨씬 늦게 나타났습니다.

• 최초의 객체 지향 언어는 노르웨이 컴퓨팅 센터의 연구원이 1960 년에 개발 한 Simula (실제 시스템 시뮬레이션)입니다.

• 1970 년 Xerox PARK의 Alan Kay와 그의 연구 그룹은 Dynabook을 프로그래밍하기 위해 Dynabook이라는 개인용 컴퓨터와 최초의 순수 객체 지향 프로그래밍 언어 (OOPL) 인 Smalltalk를 만들었습니다.

• 1980 년대에 Grady Booch는 주로 프로그래밍 언어 인 Ada를위한 디자인을 제시하는 Object Oriented Design이라는 제목의 논문을 발표했습니다. 이어지는 에디션에서 그는 자신의 아이디어를 완전한 객체 지향 디자인 방법으로 확장했습니다.

• 1990 년대에 Coad는 행동 아이디어를 객체 지향 방법에 통합했습니다.

다른 중요한 혁신은 James Rumbaugh의 OMT (Object Modeling Techniques)와 Ivar Jacobson의 OOSE (Object-Oriented Software Engineering)였습니다.

객체 지향 분석

객체 지향 분석 (OOA)은 상호 작용하는 객체로 구성된 소프트웨어 시스템의 객체 모델 측면에서 소프트웨어 엔지니어링 요구 사항을 식별하고 소프트웨어 사양을 개발하는 절차입니다.

객체 지향 분석과 다른 형태의 분석의 주요 차이점은 객체 지향 접근 방식에서 요구 사항은 데이터와 기능을 모두 통합하는 객체를 중심으로 구성된다는 것입니다. 시스템이 상호 작용하는 실제 개체를 모델로합니다. 전통적인 분석 방법에서는 기능과 데이터라는 두 가지 측면이 별도로 고려됩니다.

Grady Booch는 OOA를 "객체 지향 분석은 문제 영역의 어휘에서 발견되는 클래스 및 객체의 관점에서 요구 사항을 검사하는 분석 방법"으로 정의했습니다 .

객체 지향 분석 (OOA)의 주요 작업은 다음과 같습니다.

• 개체 식별
• 개체 모델 다이어그램을 만들어 개체 구성
• 개체의 내부 또는 개체 속성 정의
• 개체의 동작, 즉 개체 동작 정의
• 개체가 상호 작용하는 방식 설명

OOA에서 사용되는 일반적인 모델은 사용 사례와 개체 모델입니다.

객체 지향 디자인

객체 지향 설계 (OOD)에는 객체 지향 분석 중에 생성 된 개념 모델의 구현이 포함됩니다. OOD에서는 기술에 독립적 인 분석 모델의 개념이 구현 클래스에 매핑되고 제약 조건이 식별되고 인터페이스가 설계되어 솔루션 도메인에 대한 모델, 즉 시스템이 어떻게 작동해야하는지에 대한 자세한 설명이 생성됩니다. 구체적인 기술을 기반으로합니다.

구현 세부 사항은 일반적으로 다음과 같습니다.

• 클래스 데이터 재구성 (필요한 경우),
• 방법의 구현, 즉 내부 데이터 구조 및 알고리즘
• 제어 구현 및
• 협회 구현.

Grady Booch는 객체 지향 설계를 "객체 지향 분해 프로세스를 포괄하는 설계 방법과 설계중인 시스템의 논리적 및 물리적 모델뿐 아니라 정적 및 동적 모델을 묘사하기위한 표기법"으로 정의했습니다 .

객체 지향 프로그래밍

객체 지향 프로그래밍 (OOP)은 모듈 성과 재사용 성의 장점을 통합하는 것을 목표로하는 객체 (데이터와 메서드 모두 포함)를 기반으로하는 프로그래밍 패러다임입니다. 일반적으로 클래스의 인스턴스 인 개체는 응용 프로그램과 컴퓨터 프로그램을 디자인하기 위해 서로 상호 작용하는 데 사용됩니다.

객체 지향 프로그래밍의 중요한 기능은 다음과 같습니다.

• 프로그램 설계의 상향식 접근 방식
• 객체를 중심으로 구성된 프로그램, 클래스별로 그룹화
• 객체의 데이터를 조작하는 방법으로 데이터에 집중
• 함수를 통한 객체 간의 상호 작용
• 기존 클래스에 기능을 추가하여 새로운 클래스 생성을 통한 디자인 재사용

객체 지향 프로그래밍 언어의 몇 가지 예는 C ++, Java, Smalltalk, Delphi, C #, Perl, Python, Ruby 및 PHP입니다.

Grady Booch는 객체 지향 프로그래밍을 “프로그램이 객체의 협력 적 컬렉션으로 구성되는 구현 방법 으로 정의 했습니다. 각 객체는 일부 클래스의 인스턴스를 나타내며 해당 클래스는 상속 관계를 통해 통합 된 클래스 계층의 구성원입니다. ” .

개체 모델은 개체 측면에서 소프트웨어 응용 프로그램의 요소를 시각화합니다. 이 장에서는 객체 지향 시스템의 기본 개념과 용어를 살펴 보겠습니다.

개체 및 클래스

객체와 클래스의 개념은 본질적으로 서로 연결되어 있으며 객체 지향 패러다임의 기반을 형성합니다.

목적

객체는 물리적 또는 개념적 존재를 가질 수있는 객체 지향 환경의 실제 요소입니다. 각 개체는-

• 시스템의 다른 개체와 구별하는 ID입니다.

• 개체의 특성 속성과 개체가 보유하는 속성 값을 결정하는 상태입니다.

• 상태 변경 측면에서 개체가 수행 한 외부에서 볼 수있는 활동을 나타내는 동작입니다.

응용 프로그램의 필요에 따라 개체를 모델링 할 수 있습니다. 객체는 고객, 자동차 등과 같은 물리적 존재를 가질 수 있습니다. 또는 프로젝트, 프로세스 등과 같은 무형의 개념적 존재.

수업

클래스는 일반적인 동작을 나타내는 동일한 특성 속성을 가진 개체 모음을 나타냅니다. 생성 할 수있는 개체의 청사진 또는 설명을 제공합니다. 개체를 클래스의 구성원으로 만드는 것을 인스턴스화라고합니다. 따라서 객체는 클래스의 인스턴스입니다.

클래스의 구성 요소는 다음과 같습니다.

• 클래스에서 인스턴스화 할 개체에 대한 속성 집합입니다. 일반적으로 클래스의 다른 객체는 속성 값에 약간의 차이가 있습니다. 속성은 종종 클래스 데이터라고합니다.

• 클래스 객체의 동작을 나타내는 일련의 작업입니다. 작업은 기능 또는 방법이라고도합니다.

Example

2 차원 공간에서 기하학적 도형 원을 나타내는 간단한 클래스 Circle을 고려해 보겠습니다. 이 클래스의 속성은 다음과 같이 식별 할 수 있습니다.

• x 좌표, 중심의 x 좌표를 나타냅니다.
• y 좌표, 중심의 y 좌표를 나타냅니다.
• a, 원의 반경을 나타냅니다.

일부 작업은 다음과 같이 정의 할 수 있습니다.

• findArea (), 면적 계산 방법
• findCircumference (), 둘레를 계산하는 방법
• scale (), 반경을 늘리거나 줄이는 방법

인스턴스화하는 동안 최소한 일부 속성에 값이 할당됩니다. my_circle 객체를 생성하면 x-coord : 2, y-coord : 3, a : 4와 같은 값을 할당하여 상태를 나타낼 수 있습니다. 이제 스케일링 계수가 2 인 my_circle에 대해 scale () 연산을 수행하면 변수 a의 값이 8이됩니다.이 연산은 my_circle의 상태를 변경합니다. 즉, 객체가 특정 동작을 나타냅니다.

캡슐화 및 데이터 숨기기

캡슐화

캡슐화는 클래스 내에서 속성과 메서드를 함께 바인딩하는 프로세스입니다. 캡슐화를 통해 클래스의 내부 세부 정보를 외부에서 숨길 수 있습니다. 클래스가 제공하는 인터페이스를 통해서만 외부에서 클래스의 요소에 액세스 할 수 있습니다.

데이터 숨기기

일반적으로 클래스는 클래스 메서드를 통해서만 데이터 (속성)에 액세스 할 수 있고 직접적인 외부 액세스로부터 격리되도록 설계되었습니다. 개체의 데이터를 격리하는이 과정을 데이터 숨김 또는 정보 숨김이라고합니다.

Example

Circle 클래스에서 데이터 숨김은 클래스 외부에서 속성을 보이지 않게 만들고 클래스 데이터에 액세스하기 위해 클래스에 두 가지 메서드를 추가하여 통합 할 수 있습니다.

• setValues ​​(), x 좌표, y 좌표 및 a에 값을 할당하는 메서드
• getValues ​​(), x 좌표, y 좌표 및 a의 값을 검색하는 메서드

여기서 my_circle 개체의 개인 데이터는 Circle 클래스 내에서 캡슐화되지 않은 메서드로 직접 액세스 할 수 없습니다. 대신 setValues ​​() 및 getValues ​​() 메소드를 통해 액세스해야합니다.

메시지 전달

모든 응용 프로그램에는 조화로운 방식으로 상호 작용하는 여러 개체가 필요합니다. 시스템의 개체는 메시지 전달을 사용하여 서로 통신 할 수 있습니다. 시스템에 obj1 및 obj2의 두 개체가 있다고 가정합니다. obj1이 obj2가 메서드 중 하나를 실행하도록하려는 경우 개체 obj1은 개체 obj2에 메시지를 보냅니다.

메시지 전달의 특징은-

• 두 개체 간의 메시지 전달은 일반적으로 단방향입니다.
• 메시지 전달은 개체 간의 모든 상호 작용을 가능하게합니다.
• 메시지 전달에는 기본적으로 클래스 메서드 호출이 포함됩니다.
• 다른 프로세스의 개체가 메시지 전달에 포함될 수 있습니다.

계승

상속은 기능을 확장하고 개선하여 기존 클래스에서 새 클래스를 만들 수있는 메커니즘입니다. 기존 클래스를 기본 클래스 / 부모 클래스 / 수퍼 클래스라고하고 새 클래스를 파생 클래스 / 자식 클래스 / 하위 클래스라고합니다. 하위 클래스는 수퍼 클래스가 허용하는 경우 수퍼 클래스의 속성 및 메서드를 상속하거나 파생 할 수 있습니다. 게다가, 서브 클래스는 자체 속성과 메소드를 추가 할 수 있으며 수퍼 클래스 메소드를 수정할 수 있습니다. 상속은 "is – a"관계를 정의합니다.

Example

Mammal 클래스에서 Human, Cat, Dog, Cow 등과 같은 여러 클래스가 파생 될 수 있습니다. 인간, 고양이, 개 및 소는 모두 포유류의 고유 한 특성을 가지고 있습니다. 또한 각각 고유 한 특성이 있습니다. 소는 포유류라고 할 수 있습니다.

상속 유형

• Single Inheritance − 하위 클래스는 단일 수퍼 클래스에서 파생됩니다.

• Multiple Inheritance − 서브 클래스는 하나 이상의 슈퍼 클래스에서 파생됩니다.

• Multilevel Inheritance − 서브 클래스는 다른 클래스에서 파생되는 수퍼 클래스에서 파생됩니다.

• Hierarchical Inheritance − 한 클래스에는 여러 하위 클래스가 있으며, 각 하위 클래스는 후속 하위 클래스를 가질 수 있으며 트리 구조를 형성하기 위해 여러 수준에 걸쳐 계속됩니다.

• Hybrid Inheritance − 격자 구조를 형성하기위한 다중 및 다중 수준 상속의 조합.

다음 그림은 다양한 상속 유형의 예를 보여줍니다.

다형성

다형성은 원래 여러 형태를 취할 수있는 능력을 의미하는 그리스어 단어입니다. 객체 지향 패러다임에서 다형성은 작동하는 인스턴스에 따라 다른 방식으로 작업을 사용하는 것을 의미합니다. 다형성은 내부 구조가 다른 객체가 공통 외부 인터페이스를 갖도록합니다. 다형성은 상속을 구현하는 동안 특히 효과적입니다.

Example

각각 findArea () 메소드가있는 Circle과 Square의 두 클래스를 고려해 보겠습니다. 클래스에 포함 된 메서드의 이름과 목적은 동일하지만 내부 구현 즉 면적 계산 절차는 클래스마다 다릅니다. Circle 클래스의 객체가 findArea () 메서드를 호출하면 작업은 Square 클래스의 findArea () 메서드와 충돌하지 않고 원의 영역을 찾습니다.

일반화 및 전문화

일반화 및 전문화는 클래스 간의 관계 계층 구조를 나타내며 하위 클래스는 수퍼 클래스에서 상속됩니다.

일반화

일반화 과정에서 클래스의 공통 특성이 결합되어 상위 계층의 클래스를 형성합니다. 즉, 하위 클래스가 결합되어 일반화 된 수퍼 클래스를 형성합니다. 그것은“is – a – – 일종의 – –”관계를 나타냅니다. 예를 들어, "자동차는 일종의 육상 차량입니다"또는 "선박은 일종의 수상 차량"입니다.

전문화

전문화는 일반화의 역 과정입니다. 여기서 객체 그룹의 구별되는 기능은 기존 클래스와 특수 클래스를 형성하는 데 사용됩니다. 하위 클래스는 수퍼 클래스의 특수 버전이라고 할 수 있습니다.

다음 그림은 일반화 및 전문화의 예를 보여줍니다.

링크 및 연결

링크

링크는 개체가 다른 개체와 공동 작업하는 연결을 나타냅니다. Rumbaugh는이를 "물체 간의 물리적 또는 개념적 연결"로 정의했습니다. 링크를 통해 한 개체가 메서드를 호출하거나 다른 개체를 탐색 할 수 있습니다. 링크는 둘 이상의 개체 간의 관계를 나타냅니다.

협회

연관은 공통 구조와 공통 동작을 갖는 링크 그룹입니다. 연관은 하나 이상의 클래스 개체 간의 관계를 나타냅니다. 링크는 연관의 인스턴스로 정의 될 수 있습니다.

협회의 정도

연관 정도는 연결에 관련된 클래스의 수를 나타냅니다. 차수는 단항, 이진 또는 삼항 일 수 있습니다.

• A unary relationship connects objects of the same class.

• A binary relationship connects objects of two classes.

• A ternary relationship connects objects of three or more classes.

Cardinality Ratios of Associations

Cardinality of a binary association denotes the number of instances participating in an association. There are three types of cardinality ratios, namely −

• One–to–One − A single object of class A is associated with a single object of class B.

• One–to–Many − A single object of class A is associated with many objects of class B.

• Many–to–Many − An object of class A may be associated with many objects of class B and conversely an object of class B may be associated with many objects of class A.

Aggregation or Composition

Aggregation or composition is a relationship among classes by which a class can be made up of any combination of objects of other classes. It allows objects to be placed directly within the body of other classes. Aggregation is referred as a “part–of” or “has–a” relationship, with the ability to navigate from the whole to its parts. An aggregate object is an object that is composed of one or more other objects.

Example

In the relationship, “a car has–a motor”, car is the whole object or the aggregate, and the motor is a “part–of” the car. Aggregation may denote −

• Physical containment − Example, a computer is composed of monitor, CPU, mouse, keyboard, and so on.

• Conceptual containment − Example, shareholder has–a share.

Benefits of Object Model

Now that we have gone through the core concepts pertaining to object orientation, it would be worthwhile to note the advantages that this model has to offer.

The benefits of using the object model are −

• It helps in faster development of software.

• It is easy to maintain. Suppose a module develops an error, then a programmer can fix that particular module, while the other parts of the software are still up and running.

• It supports relatively hassle-free upgrades.

• It enables reuse of objects, designs, and functions.

• It reduces development risks, particularly in integration of complex systems.

We know that the Object-Oriented Modelling (OOM) technique visualizes things in an application by using models organized around objects. Any software development approach goes through the following stages −

• Analysis,
• Design, and
• Implementation.

In object-oriented software engineering, the software developer identifies and organizes the application in terms of object-oriented concepts, prior to their final representation in any specific programming language or software tools.

Phases in Object-Oriented Software Development

The major phases of software development using object–oriented methodology are object-oriented analysis, object-oriented design, and object-oriented implementation.

Object–Oriented Analysis

In this stage, the problem is formulated, user requirements are identified, and then a model is built based upon real–world objects. The analysis produces models on how the desired system should function and how it must be developed. The models do not include any implementation details so that it can be understood and examined by any non–technical application expert.

Object–Oriented Design

Object-oriented design includes two main stages, namely, system design and object design.

System Design

In this stage, the complete architecture of the desired system is designed. The system is conceived as a set of interacting subsystems that in turn is composed of a hierarchy of interacting objects, grouped into classes. System design is done according to both the system analysis model and the proposed system architecture. Here, the emphasis is on the objects comprising the system rather than the processes in the system.

Object Design

In this phase, a design model is developed based on both the models developed in the system analysis phase and the architecture designed in the system design phase. All the classes required are identified. The designer decides whether −

• new classes are to be created from scratch,
• any existing classes can be used in their original form, or
• new classes should be inherited from the existing classes.

The associations between the identified classes are established and the hierarchies of classes are identified. Besides, the developer designs the internal details of the classes and their associations, i.e., the data structure for each attribute and the algorithms for the operations.

Object–Oriented Implementation and Testing

In this stage, the design model developed in the object design is translated into code in an appropriate programming language or software tool. The databases are created and the specific hardware requirements are ascertained. Once the code is in shape, it is tested using specialized techniques to identify and remove the errors in the code.

Principles of Object-Oriented Systems

The conceptual framework of object–oriented systems is based upon the object model. There are two categories of elements in an object-oriented system −

Major Elements − By major, it is meant that if a model does not have any one of these elements, it ceases to be object oriented. The four major elements are −

• Abstraction
• Encapsulation
• Modularity
• Hierarchy

Minor Elements − By minor, it is meant that these elements are useful, but not indispensable part of the object model. The three minor elements are −

• Typing
• Concurrency
• Persistence

Abstraction

Abstraction means to focus on the essential features of an element or object in OOP, ignoring its extraneous or accidental properties. The essential features are relative to the context in which the object is being used.

Grady Booch has defined abstraction as follows −

“An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.”

Example − When a class Student is designed, the attributes enrolment_number, name, course, and address are included while characteristics like pulse_rate and size_of_shoe are eliminated, since they are irrelevant in the perspective of the educational institution.

Encapsulation

Encapsulation is the process of binding both attributes and methods together within a class. Through encapsulation, the internal details of a class can be hidden from outside. The class has methods that provide user interfaces by which the services provided by the class may be used.

Modularity

Modularity is the process of decomposing a problem (program) into a set of modules so as to reduce the overall complexity of the problem. Booch has defined modularity as −

“Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.”

Modularity is intrinsically linked with encapsulation. Modularity can be visualized as a way of mapping encapsulated abstractions into real, physical modules having high cohesion within the modules and their inter–module interaction or coupling is low.

Hierarchy

In Grady Booch’s words, “Hierarchy is the ranking or ordering of abstraction”. Through hierarchy, a system can be made up of interrelated subsystems, which can have their own subsystems and so on until the smallest level components are reached. It uses the principle of “divide and conquer”. Hierarchy allows code reusability.

The two types of hierarchies in OOA are −

• “IS–A” hierarchy − It defines the hierarchical relationship in inheritance, whereby from a super-class, a number of subclasses may be derived which may again have subclasses and so on. For example, if we derive a class Rose from a class Flower, we can say that a rose “is–a” flower.

• “PART–OF” hierarchy − It defines the hierarchical relationship in aggregation by which a class may be composed of other classes. For example, a flower is composed of sepals, petals, stamens, and carpel. It can be said that a petal is a “part–of” flower.

Typing

According to the theories of abstract data type, a type is a characterization of a set of elements. In OOP, a class is visualized as a type having properties distinct from any other types. Typing is the enforcement of the notion that an object is an instance of a single class or type. It also enforces that objects of different types may not be generally interchanged; and can be interchanged only in a very restricted manner if absolutely required to do so.

The two types of typing are −

• Strong Typing − Here, the operation on an object is checked at the time of compilation, as in the programming language Eiffel.

• Weak Typing − Here, messages may be sent to any class. The operation is checked only at the time of execution, as in the programming language Smalltalk.

Concurrency

Concurrency in operating systems allows performing multiple tasks or processes simultaneously. When a single process exists in a system, it is said that there is a single thread of control. However, most systems have multiple threads, some active, some waiting for CPU, some suspended, and some terminated. Systems with multiple CPUs inherently permit concurrent threads of control; but systems running on a single CPU use appropriate algorithms to give equitable CPU time to the threads so as to enable concurrency.

In an object-oriented environment, there are active and inactive objects. The active objects have independent threads of control that can execute concurrently with threads of other objects. The active objects synchronize with one another as well as with purely sequential objects.

Persistence

An object occupies a memory space and exists for a particular period of time. In traditional programming, the lifespan of an object was typically the lifespan of the execution of the program that created it. In files or databases, the object lifespan is longer than the duration of the process creating the object. This property by which an object continues to exist even after its creator ceases to exist is known as persistence.

In the system analysis or object-oriented analysis phase of software development, the system requirements are determined, the classes are identified and the relationships among classes are identified.

The three analysis techniques that are used in conjunction with each other for object-oriented analysis are object modelling, dynamic modelling, and functional modelling.

Object Modelling

Object modelling develops the static structure of the software system in terms of objects. It identifies the objects, the classes into which the objects can be grouped into and the relationships between the objects. It also identifies the main attributes and operations that characterize each class.

The process of object modelling can be visualized in the following steps −

• Identify objects and group into classes
• Identify the relationships among classes
• Create user object model diagram
• Define user object attributes
• Define the operations that should be performed on the classes
• Review glossary

Dynamic Modelling

After the static behavior of the system is analyzed, its behavior with respect to time and external changes needs to be examined. This is the purpose of dynamic modelling.

Dynamic Modelling can be defined as “a way of describing how an individual object responds to events, either internal events triggered by other objects, or external events triggered by the outside world”.

The process of dynamic modelling can be visualized in the following steps −

• Identify states of each object
• Identify events and analyze the applicability of actions
• Construct dynamic model diagram, comprising of state transition diagrams
• Express each state in terms of object attributes
• Validate the state–transition diagrams drawn

Functional Modelling

Functional Modelling is the final component of object-oriented analysis. The functional model shows the processes that are performed within an object and how the data changes as it moves between methods. It specifies the meaning of the operations of object modelling and the actions of dynamic modelling. The functional model corresponds to the data flow diagram of traditional structured analysis.

The process of functional modelling can be visualized in the following steps −

• Identify all the inputs and outputs
• Construct data flow diagrams showing functional dependencies
• State the purpose of each function
• Identify constraints
• Specify optimization criteria

Structured Analysis vs. Object Oriented Analysis

The Structured Analysis/Structured Design (SASD) approach is the traditional approach of software development based upon the waterfall model. The phases of development of a system using SASD are −

• Feasibility Study
• Requirement Analysis and Specification
• System Design
• Implementation
• Post-implementation Review

Now, we will look at the relative advantages and disadvantages of structured analysis approach and object-oriented analysis approach.

Advantages/Disadvantages of Object Oriented Analysis

Advantages	Disadvantages
Focuses on data rather than the procedures as in Structured Analysis.	Functionality is restricted within objects. This may pose a problem for systems which are intrinsically procedural or computational in nature.
The principles of encapsulation and data hiding help the developer to develop systems that cannot be tampered by other parts of the system.	It cannot identify which objects would generate an optimal system design.
The principles of encapsulation and data hiding help the developer to develop systems that cannot be tampered by other parts of the system.	The object-oriented models do not easily show the communications between the objects in the system.
It allows effective management of software complexity by the virtue of modularity.	All the interfaces between the objects cannot be represented in a single diagram.
It can be upgraded from small to large systems at a greater ease than in systems following structured analysis.

Advantages/Disadvantages of Structured Analysis

Advantages	Disadvantages
As it follows a top-down approach in contrast to bottom-up approach of object-oriented analysis, it can be more easily comprehended than OOA.	In traditional structured analysis models, one phase should be completed before the next phase. This poses a problem in design, particularly if errors crop up or requirements change.
It is based upon functionality. The overall purpose is identified and then functional decomposition is done for developing the software. The emphasis not only gives a better understanding of the system but also generates more complete systems.	The initial cost of constructing the system is high, since the whole system needs to be designed at once leaving very little option to add functionality later.
The specifications in it are written in simple English language, and hence can be more easily analyzed by non-technical personnel.	It does not support reusability of code. So, the time and cost of development is inherently high.

The dynamic model represents the time–dependent aspects of a system. It is concerned with the temporal changes in the states of the objects in a system. The main concepts are −

• State, which is the situation at a particular condition during the lifetime of an object.

• Transition, a change in the state

• Event, an occurrence that triggers transitions

• Action, an uninterrupted and atomic computation that occurs due to some event, and

• Concurrency of transitions.

A state machine models the behavior of an object as it passes through a number of states in its lifetime due to some events as well as the actions occurring due to the events. A state machine is graphically represented through a state transition diagram.

States and State Transitions

State

The state is an abstraction given by the values of the attributes that the object has at a particular time period. It is a situation occurring for a finite time period in the lifetime of an object, in which it fulfils certain conditions, performs certain activities, or waits for certain events to occur. In state transition diagrams, a state is represented by rounded rectangles.

Parts of a state

• Name − A string differentiates one state from another. A state may not have any name.

• Entry/Exit Actions − It denotes the activities performed on entering and on exiting the state.

• Internal Transitions − The changes within a state that do not cause a change in the state.

• Sub–states − States within states.

Initial and Final States

The default starting state of an object is called its initial state. The final state indicates the completion of execution of the state machine. The initial and the final states are pseudo-states, and may not have the parts of a regular state except name. In state transition diagrams, the initial state is represented by a filled black circle. The final state is represented by a filled black circle encircled within another unfilled black circle.

Transition

A transition denotes a change in the state of an object. If an object is in a certain state when an event occurs, the object may perform certain activities subject to specified conditions and change the state. In this case, a state−transition is said to have occurred. The transition gives the relationship between the first state and the new state. A transition is graphically represented by a solid directed arc from the source state to the destination state.

The five parts of a transition are −

• Source State − The state affected by the transition.

• Event Trigger − The occurrence due to which an object in the source state undergoes a transition if the guard condition is satisfied.

• Guard Condition − A Boolean expression which if True, causes a transition on receiving the event trigger.

• Action − An un-interruptible and atomic computation that occurs on the source object due to some event.

• Target State − The destination state after completion of transition.

Example

Suppose a person is taking a taxi from place X to place Y. The states of the person may be: Waiting (waiting for taxi), Riding (he has got a taxi and is travelling in it), and Reached (he has reached the destination). The following figure depicts the state transition.

Events

Events are some occurrences that can trigger state transition of an object or a group of objects. Events have a location in time and space but do not have a time period associated with it. Events are generally associated with some actions.

Examples of events are mouse click, key press, an interrupt, stack overflow, etc.

Events that trigger transitions are written alongside the arc of transition in state diagrams.

Example

Considering the example shown in the above figure, the transition from Waiting state to Riding state takes place when the person gets a taxi. Likewise, the final state is reached, when he reaches the destination. These two occurrences can be termed as events Get_Taxi and Reach_Destination. The following figure shows the events in a state machine.

External and Internal Events

External events are those events that pass from a user of the system to the objects within the system. For example, mouse click or key−press by the user are external events.

Internal events are those that pass from one object to another object within a system. For example, stack overflow, a divide error, etc.

Deferred Events

Deferred events are those which are not immediately handled by the object in the current state but are lined up in a queue so that they can be handled by the object in some other state at a later time.

Event Classes

Event class indicates a group of events with common structure and behavior. As with classes of objects, event classes may also be organized in a hierarchical structure. Event classes may have attributes associated with them, time being an implicit attribute. For example, we can consider the events of departure of a flight of an airline, which we can group into the following class −

Flight_Departs (Flight_No, From_City, To_City, Route)

Actions

Activity

Activity is an operation upon the states of an object that requires some time period. They are the ongoing executions within a system that can be interrupted. Activities are shown in activity diagrams that portray the flow from one activity to another.

Action

An action is an atomic operation that executes as a result of certain events. By atomic, it is meant that actions are un-interruptible, i.e., if an action starts executing, it runs into completion without being interrupted by any event. An action may operate upon an object on which an event has been triggered or on other objects that are visible to this object. A set of actions comprise an activity.

Entry and Exit Actions

Entry action is the action that is executed on entering a state, irrespective of the transition that led into it.

Likewise, the action that is executed while leaving a state, irrespective of the transition that led out of it, is called an exit action.

Scenario

Scenario is a description of a specified sequence of actions. It depicts the behavior of objects undergoing a specific action series. The primary scenarios depict the essential sequences and the secondary scenarios depict the alternative sequences.

Diagrams for Dynamic Modelling

There are two primary diagrams that are used for dynamic modelling −

Interaction Diagrams

Interaction diagrams describe the dynamic behavior among different objects. It comprises of a set of objects, their relationships, and the message that the objects send and receive. Thus, an interaction models the behavior of a group of interrelated objects. The two types of interaction diagrams are −

• Sequence Diagram − It represents the temporal ordering of messages in a tabular manner.

• Collaboration Diagram − It represents the structural organization of objects that send and receive messages through vertices and arcs.

State Transition Diagram

State transition diagrams or state machines describe the dynamic behavior of a single object. It illustrates the sequences of states that an object goes through in its lifetime, the transitions of the states, the events and conditions causing the transition and the responses due to the events.

Concurrency of Events

In a system, two types of concurrency may exist. They are −

System Concurrency

Here, concurrency is modelled in the system level. The overall system is modelled as the aggregation of state machines, where each state machine executes concurrently with others.

Concurrency within an Object

Here, an object can issue concurrent events. An object may have states that are composed of sub-states, and concurrent events may occur in each of the sub-states.

Concepts related to concurrency within an object are as follows −

Simple and Composite States

A simple state has no sub-structure. A state that has simpler states nested inside it is called a composite state. A sub-state is a state that is nested inside another state. It is generally used to reduce the complexity of a state machine. Sub-states can be nested to any number of levels.

Composite states may have either sequential sub-states or concurrent sub-states.

Sequential Sub-states

In sequential sub-states, the control of execution passes from one sub-state to another sub-state one after another in a sequential manner. There is at most one initial state and one final state in these state machines.

The following figure illustrates the concept of sequential sub-states.

Concurrent Sub-states

In concurrent sub-states, the sub-states execute in parallel, or in other words, each state has concurrently executing state machines within it. Each of the state machines has its own initial and final states. If one concurrent sub-state reaches its final state before the other, control waits at its final state. When all the nested state machines reach their final states, the sub-states join back to a single flow.

The following figure shows the concept of concurrent sub-states.

Functional Modelling gives the process perspective of the object-oriented analysis model and an overview of what the system is supposed to do. It defines the function of the internal processes in the system with the aid of Data Flow Diagrams (DFDs). It depicts the functional derivation of the data values without indicating how they are derived when they are computed, or why they need to be computed.

Data Flow Diagrams

Functional Modelling is represented through a hierarchy of DFDs. The DFD is a graphical representation of a system that shows the inputs to the system, the processing upon the inputs, the outputs of the system as well as the internal data stores. DFDs illustrate the series of transformations or computations performed on the objects or the system, and the external controls and objects that affect the transformation.

Rumbaugh et al. have defined DFD as, “A data flow diagram is a graph which shows the flow of data values from their sources in objects through processes that transform them to their destinations on other objects.”

The four main parts of a DFD are −

• Processes,
• Data Flows,
• Actors, and
• Data Stores.

The other parts of a DFD are −

• Constraints, and
• Control Flows.

Features of a DFD

Processes

Processes are the computational activities that transform data values. A whole system can be visualized as a high-level process. A process may be further divided into smaller components. The lowest-level process may be a simple function.

Representation in DFD − A process is represented as an ellipse with its name written inside it and contains a fixed number of input and output data values.

Example − The following figure shows a process Compute_HCF_LCM that accepts two integers as inputs and outputs their HCF (highest common factor) and LCM (least common multiple).

Data Flows

Data flow represents the flow of data between two processes. It could be between an actor and a process, or between a data store and a process. A data flow denotes the value of a data item at some point of the computation. This value is not changed by the data flow.

Representation in DFD − A data flow is represented by a directed arc or an arrow, labelled with the name of the data item that it carries.

In the above figure, Integer_a and Integer_b represent the input data flows to the process, while L.C.M. and H.C.F. are the output data flows.

A data flow may be forked in the following cases −

• The output value is sent to several places as shown in the following figure. Here, the output arrows are unlabelled as they denote the same value.

• The data flow contains an aggregate value, and each of the components is sent to different places as shown in the following figure. Here, each of the forked components is labelled.

Actors

Actors are the active objects that interact with the system by either producing data and inputting them to the system, or consuming data produced by the system. In other words, actors serve as the sources and the sinks of data.

Representation in DFD − An actor is represented by a rectangle. Actors are connected to the inputs and outputs and lie on the boundary of the DFD.

Example − The following figure shows the actors, namely, Customer and Sales_Clerk in a counter sales system.

Data Stores

Data stores are the passive objects that act as a repository of data. Unlike actors, they cannot perform any operations. They are used to store data and retrieve the stored data. They represent a data structure, a disk file, or a table in a database.

Representation in DFD− 데이터 저장소는 데이터 저장소의 이름을 포함하는 두 개의 평행선으로 표시됩니다. 각 데이터 저장소는 하나 이상의 프로세스에 연결됩니다. 입력 화살표에는 데이터 저장소의 내용을 수정하기위한 정보가 포함되고 출력 화살표에는 데이터 저장소에서 검색된 정보가 포함됩니다. 정보의 일부를 검색 할 때 출력 화살표에 레이블이 지정됩니다. 레이블이없는 화살표는 전체 데이터 검색을 나타냅니다. 양방향 화살표는 검색과 업데이트를 모두 의미합니다.

Example− 다음 그림은 모든 판매 내역을 저장하는 데이터 저장소 Sales_Record를 보여줍니다. 데이터 저장소에 대한 입력은 품목, 청구 금액, 날짜 등과 같은 판매 세부 정보로 구성됩니다. 평균 판매를 찾기 위해 프로세스는 판매 레코드를 검색하고 평균을 계산합니다.

제약

제약 조건은 시간이 지남에 따라 충족되어야하는 조건 또는 제한 사항을 지정합니다. 새 규칙을 추가하거나 기존 규칙을 수정할 수 있습니다. 제약 조건은 객체 지향 분석의 세 가지 모델 모두에 나타날 수 있습니다.

• 개체 모델링에서 제약 조건은 개체 간의 관계를 정의합니다. 또한 개체가 다른 시간에 취할 수있는 다른 값 간의 관계를 정의 할 수도 있습니다.

• 동적 모델링에서 제약 조건은 서로 다른 개체의 상태와 이벤트 간의 관계를 정의합니다.

• Functional Modelling에서 제약 조건은 변환 및 계산에 대한 제한을 정의합니다.

Representation − 제약 조건은 중괄호 안의 문자열로 렌더링됩니다.

Example− 다음 그림은 영업 부서의 모든 직원에게 인센티브를 제공하고 HR 부서의 모든 직원의 급여를 인상하기로 결정한 회사 직원의 급여를 계산하기위한 DFD의 일부를 보여줍니다. 제약 조건 {Dept : Sales}는 부서가 판매 인 경우에만 인센티브가 계산되도록하고 제약 {Dept : HR}은 부서가 HR 인 경우에만 증분을 계산하도록하는 것을 볼 수 있습니다.

제어 흐름

프로세스는 특정 부울 값과 연관 될 수 있으며 프로세스에 대한 직접적인 입력은 아니지만 값이 참인 경우에만 평가됩니다. 이러한 부울 값을 제어 흐름이라고합니다.

Representation in DFD − 제어 흐름은 불리언 값을 생성하는 프로세스에서 제어되는 프로세스까지 점선으로 표시됩니다.

Example− 다음 그림은 산술 분할을위한 DFD를 나타냅니다. 제수는 0이 아닌지 테스트됩니다. 0이 아닌 경우 제어 흐름 OK는 True 값을 가지며 이후에 Divide 프로세스가 몫과 나머지를 계산합니다.

시스템의 DFD 모델 개발

시스템의 DFD 모델을 개발하기 위해 DFD의 계층 구조가 구성됩니다. 최상위 레벨 DFD는 단일 프로세스와 그와 상호 작용하는 액터로 구성됩니다.

연속되는 각 하위 수준에서 추가 세부 정보가 점차적으로 포함됩니다. 프로세스를 하위 프로세스로 분해하고 하위 프로세스 간의 데이터 흐름을 식별하고 제어 흐름을 결정하며 데이터 저장소를 정의합니다. 프로세스를 분해하는 동안 프로세스로 들어 오거나 나가는 데이터 흐름은 다음 수준의 DFD에서 데이터 흐름과 일치해야합니다.

Example− 도매점의 거래를 자동화하는 소프트웨어 시스템 인 Wholesaler Software를 고려해 보겠습니다. 상점은 대량으로 판매되며 상인과 소매점 소유자로 구성된 고객이 있습니다. 각 고객은 자신의 세부 사항을 등록해야하며 고유 한 고객 코드 인 C_Code가 제공됩니다. 판매가 완료되면 상점에서 세부 정보를 등록하고 배송을 위해 상품을 보냅니다. 매해 총 매출액과 주인의 결정에 따라 은화 또는 금화로 구성된 크리스마스 선물을 고객에게 배포합니다.

도매 소프트웨어의 기능 모델은 다음과 같습니다. 아래 그림은 최상위 DFD를 보여줍니다. 소프트웨어를 단일 프로세스로 보여주고 그와 상호 작용하는 행위자를 보여줍니다.

시스템의 배우는-

• Customers
• Salesperson
• Proprietor

다음 단계 DFD에서는 다음 그림과 같이 시스템의 주요 프로세스가 식별되고 데이터 저장소가 정의되며 프로세스와 행위자와의 상호 작용 및 데이터 저장소가 설정됩니다.

시스템에서 세 가지 프로세스를 식별 할 수 있습니다.

• 고객 등록
• 프로세스 판매
• 선물 확인

필요한 데이터 저장소는-

• 고객의 세부 사항
• 판매 세부 정보
• 선물 정보

다음 그림은 고객 등록 프로세스의 세부 사항을 보여줍니다. 여기에는 세부 정보 확인, C_Code 생성 및 고객 세부 정보 업데이트의 세 가지 프로세스가 있습니다. 고객의 세부 사항을 입력하면 확인됩니다. 데이터가 올 바르면 C_Code가 생성되고 데이터 저장소 Customer Details가 업데이트됩니다.

다음 그림은 선물 확인 프로세스의 확장을 보여줍니다. 여기에는 총 판매 찾기 및 선물 코인 유형 결정의 두 가지 프로세스가 있습니다. 총 매출 찾기 프로세스는 각 고객에 해당하는 연간 총 매출을 계산하고 데이터를 기록합니다. 이 기록과 소유자의 결정을 입력으로 받아 선물 코인 결정 유형 프로세스를 통해 선물 코인이 할당됩니다.

DFD의 장단점

장점	단점
DFD는 시스템의 경계를 묘사하므로 시스템 내에서 외부 개체와 프로세스 간의 관계를 나타내는 데 도움이됩니다.	DFD는 만드는 데 오랜 시간이 걸리며 실제 목적으로는 불가능할 수 있습니다.
사용자가 시스템에 대한 지식을 갖도록 도와줍니다.	DFD는 시간에 따른 동작에 대한 정보를 제공하지 않습니다. 즉, 변환이 완료되는시기를 지정하지 않습니다.
그래픽 표현은 프로그래머가 시스템을 개발하기위한 청사진 역할을합니다.	그들은 계산의 빈도 나 계산 이유에 대해 어떤 빛도 던지지 않습니다.
DFD는 시스템 프로세스에 대한 자세한 정보를 제공합니다.	DFD 준비는 상당한 전문 지식이 필요한 복잡한 프로세스입니다. 또한 비전문가도 이해하기 어렵습니다.
시스템 문서의 일부로 사용됩니다.	준비 방법은 주관적이며 부정확 할 수있는 충분한 범위를 남깁니다.

개체, 동적 및 기능 모델 간의 관계

객체 모델, 동적 모델 및 기능 모델은 완전한 객체 지향 분석을 위해 서로 보완 적입니다.

• 객체 모델링은 객체 측면에서 소프트웨어 시스템의 정적 구조를 개발합니다. 따라서 시스템의 "실행자"를 보여줍니다.

• 동적 모델링은 외부 이벤트에 대한 응답으로 객체의 시간적 동작을 개발합니다. 개체에 대해 수행 된 작업 순서를 보여줍니다.

• 기능 모델은 시스템이 수행해야하는 작업에 대한 개요를 제공합니다.

기능 모델 및 개체 모델

객체 모델 측면에서 기능 모델의 네 가지 주요 부분은 다음과 같습니다.

• Process − 프로세스는 구현해야하는 객체의 방법을 의미합니다.

• Actors − 액터는 객체 모델의 객체입니다.

• Data Stores − 이들은 개체 모델의 개체 또는 개체의 속성입니다.

• Data Flows− 행위자와의 데이터 흐름은 객체에 대한 작업을 나타냅니다. 데이터 저장소를 오가는 데이터 흐름은 쿼리 또는 업데이트를 나타냅니다.

기능적 모델 및 동적 모델

동적 모델은 작업이 수행되는시기를 나타내며 기능적 모델은 작업이 수행되는 방식과 필요한 인수를 나타냅니다. 액터는 활성 개체이므로 동적 모델은 작동시기를 지정해야합니다. 데이터 저장소는 수동 개체이며 업데이트 및 쿼리에만 응답합니다. 따라서 동적 모델은 작동시기를 지정할 필요가 없습니다.

개체 모델 및 동적 모델

동적 모델은 개체의 상태와 이벤트 발생시 수행 된 작업 및 후속 상태 변경을 보여줍니다. 변경 결과로 개체의 상태가 개체 모델에 표시됩니다.

UML (Unified Modeling Language)은 소프트웨어 시스템의 청사진을 작성하는 표준 방법을 제공하는 OOAD 용 그래픽 언어입니다. 객체 지향 시스템의 아티팩트를 시각화, 지정, 구성 및 문서화하는 데 도움이됩니다. 복잡한 시스템의 구조와 관계를 묘사하는 데 사용됩니다.

약력

1990 년대에 Grady Booch의 OOAD 기술, James Rumbaugh의 OMT (Object Modeling Technique), Ivar Jacobson의 OOSE (Object Oriented Software Engineering) 등 여러 기술의 융합으로 개발되었습니다. UML은 OOAD의 의미 모델, 구문 표기법 및 다이어그램을 표준화하려고 시도했습니다.

UML의 시스템 및 모델

System− 특정 목표를 달성하기 위해 구성된 일련의 요소가 시스템을 형성합니다. 시스템은 종종 하위 시스템으로 나뉘며 일련의 모델로 설명됩니다.

Model − 모델은 시스템에 대한 더 나은 이해를 위해 생성 된 단순화되고 완전하며 일관된 시스템 추상화입니다.

View − 뷰는 특정 관점에서 시스템 모델을 투영 한 것입니다.

UML의 개념 모델

UML의 개념 모델은 세 가지 주요 요소를 포함합니다.

• 기본 구성 요소
• Rules
• 일반적인 메커니즘

기본 빌딩 블록

UML의 세 가지 구성 요소는 다음과 같습니다.

• Things
• Relationships
• Diagrams

소지품

UML에는 네 가지 종류가 있습니다.

• Structural Things− 이들은 물리적이거나 개념적인 정적 요소를 나타내는 UML 모델의 명사입니다. 구조적 요소는 클래스, 인터페이스, 협업, 사용 사례, 활성 클래스, 구성 요소 및 노드입니다.

• Behavioral Things− 시간과 공간에 따른 동적 동작을 나타내는 UML 모델의 동사입니다. 두 가지 유형의 행동은 상호 작용과 상태 머신입니다.

• Grouping Things− UML 모델의 구성 부분을 구성합니다. 그룹화의 종류는 단 한 가지, 즉 패키지입니다.

• Annotational Things − 설명 요소에 적용된 주석을 나타내는 UML 모델의 설명입니다.

관계

관계는 사물 간의 연결입니다. UML로 표현할 수있는 네 가지 유형의 관계는 다음과 같습니다.

• Dependency− 이것은 한 가지 변화가 다른 것에도 변화를 가져 오는 두 사물 간의 의미 론적 관계입니다. 전자는 독립적 인 것이고 후자는 종속적 인 것입니다.

• Association − 이것은 공통 구조와 공통 동작을 갖는 링크 그룹을 나타내는 구조적 관계입니다.

• Generalization − 이것은 서브 클래스가 슈퍼 클래스의 구조와 동작을 상속하는 일반화 / 특화 관계를 나타냅니다.

• Realization − 이것은 하나의 분류자가 다른 분류자가 준수하도록 보장하는 계약을 작성하는 두 개 이상의 분류 자 ​​간의 의미 관계입니다.

다이어그램

다이어그램은 시스템을 그래픽으로 표현한 것입니다. 일반적으로 그래프 형태의 요소 그룹으로 구성됩니다. UML은 모두 9 개의 다이어그램을 포함합니다.

• 클래스 다이어그램
• 개체 다이어그램
• 사용 사례 다이어그램
• 시퀀스 다이어그램
• 협업 다이어그램
• 상태 차트 다이어그램
• 활동 다이어그램
• 구성 요소 다이어그램
• 배포 다이어그램

규칙

UML에는 모델이 의미 상 자체 일관성이 있고 시스템의 다른 모델과 조화롭게 관련되도록 여러 규칙이 있습니다. UML에는 다음에 대한 의미 규칙이 있습니다.

• Names
• Scope
• Visibility
• Integrity
• Execution

일반적인 메커니즘

UML에는 네 가지 공통 메커니즘이 있습니다.

• Specifications
• Adornments
• 공통 부문
• 확장 성 메커니즘

명세서

UML에서는 각 그래픽 표기법 뒤에 구문과 의미를 나타내는 텍스트 문이 있습니다. 사양입니다. 사양은 시스템의 모든 부분과 서로 다른 경로 간의 관계를 포함하는 의미 론적 백플레인을 제공합니다.

장식품

UML의 각 요소에는 고유 한 그래픽 표기법이 있습니다. 게다가 이름, 범위, 가시성 등과 같은 요소의 중요한 측면을 나타내는 표기법이 있습니다.

공통 부문

객체 지향 시스템은 여러 가지 방법으로 나눌 수 있습니다. 두 가지 일반적인 분할 방법은 다음과 같습니다.

• Division of classes and objects− 클래스는 유사한 객체 그룹의 추상화입니다. 개체는 시스템에 실제로 존재하는 구체적인 인스턴스입니다.

• Division of Interface and Implementation− 인터페이스는 상호 작용에 대한 규칙을 정의합니다. 구현은 인터페이스에 정의 된 규칙의 구체적인 실현입니다.

확장 성 메커니즘

UML은 개방형 언어입니다. 시스템 요구 사항에 맞게 제어 된 방식으로 UML의 기능을 확장 할 수 있습니다. 확장 성 메커니즘은 다음과 같습니다.

• Stereotypes − UML의 어휘를 확장하여 기존 빌딩 블록에서 새로운 빌딩 블록을 만들 수 있습니다.

• Tagged Values − UML 빌딩 블록의 속성을 확장합니다.

• Constraints − UML 빌딩 블록의 의미를 확장합니다.

UML은 각 빌딩 블록에 대한 특정 표기법을 정의합니다.

수업

클래스는 세 개의 섹션이있는 직사각형으로 표시됩니다.

• 클래스 이름을 포함하는 상단 섹션
• 클래스 속성을 포함하는 중간 섹션
• 클래스의 작업을 나타내는 하단 섹션

속성 및 작업의 가시성은 다음과 같은 방법으로 표현할 수 있습니다.

• Public− 공개 멤버는 시스템의 어느 곳에서나 볼 수 있습니다. 클래스 다이어그램에서는 기호 '+'가 접두사로 붙습니다.

• Private− 비공개 멤버는 클래스 내에서만 볼 수 있습니다. 클래스 외부에서는 액세스 할 수 없습니다. 개인 멤버 앞에는 기호 '-'가 붙습니다.

• Protected− 보호 된 멤버는 클래스 내부와이 클래스에서 상속 된 하위 클래스에서 볼 수 있지만 외부에서는 볼 수 없습니다. 앞에 '#'기호가 붙습니다.

추상 클래스에는 이탤릭체로 작성된 클래스 이름이 있습니다.

Example− 앞서 소개 한 Circle 클래스를 살펴 보겠습니다. Circle의 속성은 x 좌표, y 좌표 및 반경입니다. 작업은 findArea (), findCircumference () 및 scale ()입니다. x-coord 및 y-coord는 개인 데이터 멤버이고, 반경은 보호 된 데이터 멤버이며, 멤버 함수는 공용이라고 가정 해 보겠습니다. 다음 그림은 클래스의 다이어그램 표현을 제공합니다.

목적

객체는 두 개의 섹션이있는 직사각형으로 표시됩니다.

• 맨 위 섹션에는 인스턴스가 속한 클래스 또는 패키지의 이름과 함께 객체 이름이 포함됩니다. 이름은 다음과 같은 형식을 취합니다.

  • object-name − 클래스 이름

  • object-name − 클래스 이름 :: 패키지 이름

  • class-name − 익명 객체의 경우

• 하단 섹션은 속성 값을 나타냅니다. 속성 이름 = 값 형식을 취합니다.

• 때때로 객체는 둥근 직사각형을 사용하여 표현됩니다.

Example− c1이라는 클래스 Circle의 객체를 고려해 보겠습니다. c1의 중심이 (2, 3)에 있고 c1의 반지름이 5라고 가정합니다. 다음 그림은 객체를 나타냅니다.

구성 요소

구성 요소는 인터페이스 집합을 준수하고 구현을 제공하는 시스템의 물리적이고 교체 가능한 부분입니다. 클래스 및 인터페이스와 같은 요소의 물리적 패키징을 나타냅니다.

Notation − UML 다이어그램에서 컴포넌트는 아래 그림과 같이 탭이있는 직사각형으로 표시됩니다.

상호 작용

인터페이스는 클래스 또는 구성 요소의 메서드 모음입니다. 클래스 또는 구성 요소에서 제공 할 수있는 서비스 집합을 지정합니다.

Notation− 일반적으로 인터페이스는 이름과 함께 원으로 그려집니다. 인터페이스는 거의 항상이를 실현하는 클래스 또는 구성 요소에 연결됩니다. 다음 그림은 인터페이스의 표기법을 제공합니다.

꾸러미

패키지는 구성 요소 그룹입니다. 패키지에는 클래스, 구성 요소 및 기타 패키지와 같은 구조적 요소가 포함될 수 있습니다.

Notation− 그래픽 적으로 패키지는 탭 폴더로 표시됩니다. 패키지는 일반적으로 이름만으로 그려집니다. 그러나 패키지 내용물에 대한 추가 세부 정보가있을 수 있습니다. 다음 그림을 참조하십시오.

관계

다른 유형의 관계에 대한 표기법은 다음과 같습니다.

일반적으로 관계의 요소는 관계에서 특정 역할을합니다. 역할 이름은 특정 컨텍스트에 참여하는 요소의 동작을 나타냅니다.

Example− 다음 그림은 클래스 간의 서로 다른 관계의 예를 보여줍니다. 첫 번째 그림은 Department와 Employee라는 두 클래스 간의 연관성을 보여줍니다. 여기서 부서에는 여러 직원이 작업 할 수 있습니다. 작업자는 역할 이름입니다. 부서 옆의 '1'과 직원 옆의 '*'는 카디널리티 비율이 일대 다임을 나타냅니다. 두 번째 그림은 집계 관계를 보여줍니다. 대학은 많은 부서의 "전체"입니다.

UML 구조 다이어그램은 클래스 다이어그램, 개체 다이어그램, 구성 요소 다이어그램 및 배포 다이어그램으로 분류됩니다.

클래스 다이어그램

클래스 다이어그램은 시스템의 정적보기를 모델링합니다. 시스템의 클래스, 인터페이스 및 협업으로 구성됩니다. 그리고 그들 사이의 관계.

시스템의 클래스 다이어그램

단순화 된 뱅킹 시스템을 고려해 보겠습니다.

은행에는 많은 지점이 있습니다. 각 구역에서 한 지점은 해당 구역의 다른 지점을 감독하는 구역 본부로 지정됩니다. 각 지점은 여러 계정과 대출을 가질 수 있습니다. 계좌는 저축 계좌 또는 당좌 계좌 일 수 있습니다. 고객은 저축 계좌와 당좌 계좌를 모두 개설 할 수 있습니다. 그러나 고객은 하나 이상의 저축 계좌 또는 당좌 계좌를 가지고 있어서는 안됩니다. 고객은 은행에서 대출을받을 수도 있습니다.

다음 그림은 해당 클래스 다이어그램을 보여줍니다.

시스템의 클래스

은행, 지점, 계좌, 저축 계좌, 당좌 계좌, 대출 및 고객.

관계

• A Bank “has–a” number of Branches − 구성, 일대 다

• A Branch with role Zonal Head Office supervises other Branches − 단항 연관, 일대 다

• A Branch “has–a” number of accounts − 집계, 일대 다

계정 클래스에서 두 클래스, 즉 저축 계정과 당좌 계정이 상속되었습니다.

• A Customer can have one Current Account − 연관, 일대일

• A Customer can have one Savings Account − 연관, 일대일

• A Branch “has–a” number of Loans − 집계, 일대 다

• A Customer can take many loans − 연관, 일대 다

개체 다이어그램

개체 다이어그램은 특정 시점에 개체 그룹과 해당 링크를 모델링합니다. 클래스 다이어그램에있는 사물의 인스턴스를 보여줍니다. 개체 다이어그램은 상호 작용 다이어그램의 정적 부분입니다.

Example − 다음 그림은 뱅킹 시스템 클래스 다이어그램의 일부에 대한 개체 다이어그램을 보여줍니다.

구성 요소 다이어그램

구성 요소 다이어그램은 구성 요소 그룹 간의 조직 및 종속성을 보여줍니다.

구성 요소 다이어그램은 다음으로 구성됩니다.

• Components
• Interfaces
• Relationships
• 패키지 및 하위 시스템 (선택 사항)

구성 요소 다이어그램은 다음에 사용됩니다.

• 포워드 및 리버스 엔지니어링을 통한 시스템 구축.

• 객체 지향 프로그래밍 언어를 사용하여 시스템을 개발하는 동안 소스 코드 파일의 구성 관리를 모델링합니다.

• 모델링 데이터베이스의 스키마를 나타냅니다.

• 동적 시스템의 모델링 동작.

Example

다음 그림은 C ++를 사용하여 개발 된 시스템의 소스 코드를 모델링하기위한 구성 요소 다이어그램을 보여줍니다. 여기에는 myheader.h, otherheader.h, priority.cpp 및 other.cpp의 네 가지 소스 코드 파일이 표시됩니다. 최신 버전에서 상위 버전까지 추적하는 두 가지 버전의 myheader.h가 표시됩니다. 파일 priority.cpp에는 other.cpp에 대한 컴파일 종속성이 있습니다. other.cpp 파일에는 otherheader.h에 대한 컴파일 종속성이 있습니다.

배포 다이어그램

배포 다이어그램은 런타임 처리 노드 및 노드에있는 해당 구성 요소의 구성에 중점을 둡니다. 일반적으로 노드와 종속성 또는 노드 간의 연관으로 구성됩니다.

배포 다이어그램은 다음에 사용됩니다.

• 일반적으로 소프트웨어 집약적 인 하드웨어 컬렉션으로 구성된 임베디드 시스템의 모델 장치.

• 클라이언트 / 서버 시스템의 토폴로지를 나타냅니다.

• 완전히 분산 된 시스템을 모델링합니다.

Example

다음 그림은 클라이언트 / 서버 아키텍처를 따르는 컴퓨터 시스템의 토폴로지를 보여줍니다. 그림은 프로세서로 구성된 서버로 스테레오 타입 화 된 노드를 보여줍니다. 그림은 시스템에 4 개 이상의 서버가 배포되었음을 나타냅니다. 서버에 연결된 클라이언트 노드는 각 노드가 워크 스테이션, 랩톱, 스캐너 또는 프린터와 같은 터미널 장치를 나타냅니다. 노드는 실제 등가물을 명확하게 나타내는 아이콘을 사용하여 표시됩니다.

UML 동작 다이어그램은 시스템의 동적 측면을 시각화, 지정, 구성 및 문서화합니다. 동작 다이어그램은 유스 케이스 다이어그램, 상호 작용 다이어그램, 상태 차트 다이어그램 및 활동 다이어그램으로 분류됩니다.

사용 사례 모델

사용 사례

사용 사례는 시스템이 수행하는 일련의 작업을 설명하여 가시적 인 결과를 산출합니다. 시스템 외부와 시스템 자체의 상호 작용을 보여줍니다. 사용 사례는 시스템의 일부는 물론 전체 시스템에 적용될 수 있습니다.

배우

행위자는 사용 사례의 사용자가 수행하는 역할을 나타냅니다. 배우는 사람 (예 : 학생, 고객), 장치 (예 : 워크 스테이션) 또는 다른 시스템 (예 : 은행, 기관) 일 수 있습니다.

다음 그림은 Student라는 액터의 표기법과 Generate Performance Report라는 사용 사례를 보여줍니다.

사용 사례 다이어그램

사용 사례 다이어그램은 시스템의 요소가 작동하는 방식과 컨텍스트에서 사용되는 방식에 대한 외부보기를 제공합니다.

사용 사례 다이어그램은 다음으로 구성됩니다.

• 사용 사례
• Actors
• 종속성, 일반화 및 연관과 같은 관계

사용 사례 다이어그램이 사용됩니다-

• 시스템의 모든 활동을 직사각형 안에 포함하고 상호 작용하여 시스템 외부의 행위자에 초점을 맞춰 시스템의 컨텍스트를 모델링합니다.

• 외부 관점에서 시스템의 요구 사항을 모델링합니다.

Example

자동 트레이딩 하우스 시스템을 고려해 보겠습니다. 시스템의 다음 기능을 가정합니다.

• 트레이딩 하우스는 개인 고객과 기업 고객의 두 가지 유형의 고객과 거래합니다.

• 고객이 주문을하면 영업 부서에서 주문을 처리하고 고객에게 청구서를 제공합니다.

• 이 시스템을 통해 관리자는 고객 계정을 관리하고 고객이 게시 한 모든 질문에 답변 할 수 있습니다.

상호 작용 다이어그램

상호 작용 다이어그램은 객체와 그 관계의 상호 작용을 묘사합니다. 또한 그들 사이에 전달 된 메시지도 포함됩니다. 상호 작용 다이어그램에는 두 가지 유형이 있습니다.

• 시퀀스 다이어그램
• 협업 다이어그램

상호 작용 다이어그램은 모델링에 사용됩니다-

• 시퀀스 다이어그램을 사용하여 시간 순서에 따른 제어 흐름.

• 협업 다이어그램을 사용하는 조직의 제어 흐름.

시퀀스 다이어그램

시퀀스 다이어그램은 시간에 따른 메시지 순서를 보여주는 상호 작용 다이어그램입니다.

Notations−이 다이어그램은 2 차원 차트 형태입니다. 상호 작용을 시작하는 개체는 x 축에 배치됩니다. 이러한 개체가 보내고받는 메시지는 위에서 아래로 시간이 증가하는 순서로 y 축을 따라 배치됩니다.

Example − 자동 거래소 시스템의 시퀀스 다이어그램은 다음 그림과 같습니다.

협업 다이어그램

협업 다이어그램은 메시지를 보내고받는 개체의 구조를 보여주는 상호 작용 다이어그램입니다.

Notations−이 다이어그램에서 상호 작용에 참여하는 객체는 정점을 사용하여 표시됩니다. 개체를 연결하는 링크는 메시지를 보내고받는 데 사용됩니다. 메시지는 레이블이있는 화살표로 표시됩니다.

Example − 자동 거래소 시스템의 협업 다이어그램은 아래 그림과 같습니다.

상태 차트 다이어그램

상태 차트 다이어그램은 한 상태에서 다른 상태로의 객체 제어 흐름을 나타내는 상태 시스템을 보여줍니다. 상태 머신은 이벤트 및 이벤트에 대한 응답으로 인해 객체가 겪는 상태 시퀀스를 나타냅니다.

상태 차트 다이어그램은 다음으로 구성됩니다.

• 상태 : 단순 또는 복합
• 상태 간 전환
• 전환을 유발하는 이벤트
• 이벤트로 인한 조치

상태 차트 다이어그램은 본질적으로 반응하는 개체를 모델링하는 데 사용됩니다.

Example

Automated Trading House System에서 Order를 객체로 모델링하고 순서를 추적 해 보겠습니다. 다음 그림은 해당 상태 차트 다이어그램을 보여줍니다.

활동 다이어그램

활동 다이어그램은 상태 머신에서 진행중인 비원 자적 작업 인 활동의 흐름을 보여줍니다. 활동은 원자 적 작업 인 작업을 초래합니다.

활동 다이어그램은 다음으로 구성됩니다.

• 활동 상태 및 작업 상태
• Transitions
• Objects

활동 다이어그램은 모델링에 사용됩니다-

• 액터가 보는대로 시스템과 상호 작용하는 워크 플로.
• 순서도를 사용하여 작업 또는 계산의 세부 사항.

Example

다음 그림은 자동 거래소 시스템의 일부에 대한 활동 다이어그램을 보여줍니다.

분석 단계 후 개념 모델은 객체 지향 설계 (OOD)를 사용하여 객체 지향 모델로 더욱 발전됩니다. OOD에서는 분석 모델의 기술 독립적 개념이 구현 클래스에 매핑되고 제약 조건이 식별되고 인터페이스가 설계되어 솔루션 도메인에 대한 모델이 생성됩니다. 요컨대, 구체적인 기술을 기반으로 시스템을 구축하는 방법을 지정하는 자세한 설명이 구성됩니다.

객체 지향 설계의 단계는 다음과 같이 식별 할 수 있습니다.

• 시스템 컨텍스트의 정의
• 시스템 아키텍처 설계
• 시스템의 개체 식별
• 디자인 모델 구축
• 개체 인터페이스 사양

시스템 디자인

객체 지향 시스템 설계에는 시스템의 컨텍스트를 정의한 다음 시스템의 아키텍처를 설계하는 작업이 포함됩니다.

• Context− 시스템 컨텍스트에는 정적 및 동적 부분이 있습니다. 시스템의 정적 컨텍스트는 하위 시스템의 계층 구조로 확장되는 전체 시스템의 간단한 블록 다이어그램을 사용하여 설계되었습니다. 서브 시스템 모델은 UML 패키지로 표시됩니다. 동적 컨텍스트는 시스템이 환경과 상호 작용하는 방식을 설명합니다. 그것은 사용하여 모델링됩니다use case diagrams.

• System Architecture− 시스템 아키텍처는 도메인 지식뿐만 아니라 아키텍처 설계의 원칙에 따라 시스템의 컨텍스트를 기반으로 설계되었습니다. 일반적으로 시스템은 계층으로 분할되고 각 계층은 분해되어 하위 시스템을 형성합니다.

객체 지향 분해

분해는 분할 및 정복 원칙에 따라 복잡한 대형 시스템을 복잡성이 적은 작은 구성 요소의 계층으로 분할하는 것을 의미합니다. 시스템의 각 주요 구성 요소를 하위 시스템이라고합니다. 객체 지향 분해는 시스템의 개별 자율 객체와 이러한 객체 간의 통신을 식별합니다.

분해의 장점은 다음과 같습니다.

• 개별 구성 요소는 덜 복잡하고 이해하기 쉽고 관리하기 쉽습니다.

• 전문 기술을 보유한 인력을 분담 할 수 있습니다.

• 다른 하위 시스템에 영향을주지 않고 하위 시스템을 교체하거나 수정할 수 있습니다.

동시성 식별

동시성을 사용하면 둘 이상의 객체가 동시에 이벤트를 수신하고 둘 이상의 활동을 동시에 실행할 수 있습니다. 동시성은 동적 모델에서 식별되고 표현됩니다.

동시성을 활성화하기 위해 각 동시 요소에는 별도의 제어 스레드가 할당됩니다. 동시성이 개체 수준이면 두 개의 동시 개체에 두 개의 다른 제어 스레드가 할당됩니다. 단일 개체의 두 작업이 본질적으로 동시에 발생하는 경우 해당 개체는 서로 다른 스레드로 분할됩니다.

동시성은 데이터 무결성, 교착 상태 및 기아 문제와 관련이 있습니다. 따라서 동시성이 필요할 때마다 명확한 전략을 세워야합니다. 또한 동시성은 설계 단계 자체에서 식별되어야하며 구현 단계에 남아있을 수 없습니다.

패턴 식별

응용 프로그램을 설계하는 동안 일부 범주의 문제에 대해 일반적으로 허용되는 일부 솔루션이 채택됩니다. 이것이 디자인 패턴입니다. 패턴은 특정 유형의 애플리케이션 개발 문제에서 사용할 수있는 문서화 된 빌딩 블록 세트로 정의 할 수 있습니다.

일반적으로 사용되는 디자인 패턴은 다음과 같습니다.

• 파사드 패턴
• 모델보기 분리 패턴
• 관찰자 패턴
• 모델보기 컨트롤러 패턴
• 구독 패턴 게시
• 프록시 패턴

이벤트 제어

시스템 설계 중에 시스템 개체에서 발생할 수있는 이벤트를 식별하고 적절하게 처리해야합니다.

이벤트는 시간과 공간에서 위치가있는 중요한 발생의 사양입니다.

모델링 할 수있는 이벤트에는 네 가지 유형이 있습니다.

• Signal Event − 한 개체에 의해 던져지고 다른 개체에 의해 잡힌 명명 된 개체.

• Call Event − 작업 발송을 나타내는 동기 이벤트.

• Time Event − 시간의 흐름을 나타내는 이벤트.

• Change Event − 상태 변화를 나타내는 이벤트.

경계 조건 처리

시스템 설계 단계에서는 시스템 전체와 각 하위 시스템의 초기화 및 종료를 처리해야합니다. 문서화 된 다른 측면은 다음과 같습니다.

• 시스템 시작, 즉 시스템이 초기화되지 않은 상태에서 정상 상태로 전환됩니다.

• 시스템 종료, 즉 실행중인 모든 스레드 닫기, 리소스 정리 및 보낼 메시지.

• 시스템의 초기 구성 및 필요할 때 시스템 재구성.

• 시스템의 실패 또는 원치 않는 종료 예측.

경계 조건은 경계 사용 사례를 사용하여 모델링됩니다.

개체 디자인

하위 시스템 계층이 개발 된 후 시스템의 개체가 식별되고 세부 정보가 설계됩니다. 여기서 설계자는 시스템 설계 중에 선택한 전략을 자세히 설명합니다. 강조점은 응용 프로그램 도메인 개념에서 컴퓨터 개념으로 이동합니다. 분석 중에 식별 된 객체는 실행 시간, 메모리 소비 및 전체 비용을 최소화하기 위해 구현을 위해 에칭됩니다.

개체 디자인에는 다음 단계가 포함됩니다.

• 개체 식별
• 객체 표현, 즉 디자인 모델의 구성
• 작업 분류
• 알고리즘 설계
• 관계 설계
• 외부 상호 작용을위한 제어 구현
• 클래스와 연관을 모듈로 패키징

개체 식별

객체 디자인의 첫 번째 단계는 객체 식별입니다. 객체 지향 분석 단계에서 식별 된 객체는 클래스로 그룹화되고 실제 구현에 적합하도록 세분화됩니다.

이 단계의 기능은-

• 각 하위 시스템 또는 패키지의 클래스 식별 및 구체화

• 클래스 간의 링크 및 연관 정의

• 클래스 간의 계층 적 연관성, 즉 일반화 / 특화 및 상속 설계

• 집계 디자인

객체 표현

클래스가 식별되면 객체 모델링 기술을 사용하여 표현해야합니다. 이 단계에는 기본적으로 UML 다이어그램 구성이 포함됩니다.

생산해야 할 두 가지 유형의 설계 모델이 있습니다.

• Static Models − 클래스 다이어그램과 객체 다이어그램을 사용하여 시스템의 정적 구조를 설명합니다.

• Dynamic Models − 시스템의 동적 구조를 설명하고 상호 작용 다이어그램과 상태 차트 다이어그램을 사용하여 클래스 간의 상호 작용을 보여줍니다.

운영 분류

이 단계에서는 OOA 단계에서 개발 된 세 가지 모델 즉, 객체 모델, 동적 모델, 기능 모델을 결합하여 객체에 대해 수행 할 작업을 정의합니다. 작업은 수행 방법이 아니라 수행 할 작업을 지정합니다.

다음 작업은 작업과 관련하여 수행됩니다-

• 시스템의 각 객체에 대한 상태 전이 다이어그램이 개발됩니다.

• 작업은 객체가 수신 한 이벤트에 대해 정의됩니다.

• 하나의 이벤트가 동일하거나 다른 개체에서 다른 이벤트를 트리거하는 경우가 식별됩니다.

• 작업 내의 하위 작업이 식별됩니다.

• 주요 작업은 데이터 흐름 다이어그램으로 확장됩니다.

알고리즘 설계

객체의 작업은 알고리즘을 사용하여 정의됩니다. 알고리즘은 작업에있는 문제를 해결하는 단계적 절차입니다. 알고리즘은 수행 방법에 중점을 둡니다.

주어진 작업에 해당하는 알고리즘이 둘 이상있을 수 있습니다. 대체 알고리즘이 식별되면 주어진 문제 영역에 대해 최적의 알고리즘이 선택됩니다. 최적의 알고리즘을 선택하기위한 메트릭은 다음과 같습니다.

• Computational Complexity − 복잡성은 계산 시간 및 메모리 요구 사항 측면에서 알고리즘의 효율성을 결정합니다.

• Flexibility − 유연성은 선택한 알고리즘이 다양한 환경에서 적절성을 잃지 않고 적절하게 구현 될 수 있는지 여부를 결정합니다.

• Understandability − 선택한 알고리즘이 이해하고 구현하기 쉬운 지 여부를 결정합니다.

관계 설계

관계를 구현하기위한 전략은 개체 디자인 단계에서 작성해야합니다. 해결되는 주요 관계는 연결, 집계 및 상속으로 구성됩니다.

디자이너는 연관성에 대해 다음을 수행해야합니다.

• 연관이 단방향인지 양방향인지 식별합니다.

• 연결 경로를 분석하고 필요한 경우 업데이트합니다.

• 다 대다 관계의 경우 연관을 별개의 개체로 구현합니다. 또는 일대일 또는 일대 다 관계의 경우 다른 개체에 대한 링크로.

상속과 관련하여 디자이너는 다음을 수행해야합니다.

• 클래스와 그 연관성을 조정하십시오.

• 추상 클래스를 식별합니다.

• 필요할 때 행동을 공유 할 수 있도록 준비하십시오.

통제의 구현

개체 설계자는 상태 차트 모델의 전략에 개선 사항을 통합 할 수 있습니다. 시스템 설계에서는 동적 모델을 실현하기위한 기본 전략이 만들어집니다. 개체 설계 중에이 전략은 적절한 구현을 위해 적절하게 장식됩니다.

동적 모델을 구현하는 방법은 다음과 같습니다.

• Represent State as a Location within a Program− 이것은 제어 위치가 프로그램 상태를 정의하는 전통적인 절차 중심 접근 방식입니다. 유한 상태 머신은 프로그램으로 구현 될 수 있습니다. 전환은 입력 문을 형성하고, 기본 제어 경로는 명령어 시퀀스를 형성하고, 분기는 조건을 형성하고, 역방향 경로는 루프 또는 반복을 형성합니다.

• State Machine Engine−이 접근 방식은 상태 머신 엔진 클래스를 통해 상태 머신을 직접 나타냅니다. 이 클래스는 애플리케이션에서 제공하는 일련의 전환 및 작업을 통해 상태 시스템을 실행합니다.

• Control as Concurrent Tasks−이 접근 방식에서 객체는 프로그래밍 언어 또는 운영 체제에서 작업으로 구현됩니다. 여기서 이벤트는 작업 간 호출로 구현됩니다. 실제 개체의 고유 한 동시성을 유지합니다.

패키징 클래스

모든 대규모 프로젝트에서는 구현을 모듈 또는 패키지로 세 심하게 분할하는 것이 중요합니다. 객체 디자인 중에 클래스와 객체는 여러 그룹이 프로젝트에서 협력 적으로 작업 할 수 있도록 패키지로 그룹화됩니다.

포장의 다른 측면은 다음과 같습니다.

• Hiding Internal Information from Outside View − 클래스를 "블랙 박스"로 볼 수 있으며 클래스의 클라이언트가 코드를 수정하지 않고도 클래스 구현을 변경할 수 있습니다.

• Coherence of Elements − 클래스, 작업 또는 모듈과 같은 요소는 일관된 계획으로 구성되고 모든 부분이 본질적으로 관련되어 공통 목표를 달성 할 수있는 경우 일관됩니다.

• Construction of Physical Modules − 다음 지침은 물리적 모듈을 구성하는 동안 도움이됩니다 −

  • 모듈의 클래스는 동일한 복합 객체에서 유사한 사물 또는 구성 요소를 나타내야합니다.

  • 밀접하게 연결된 클래스는 동일한 모듈에 있어야합니다.

  • 연결되지 않거나 약하게 연결된 클래스는 별도의 모듈에 배치해야합니다.

  • 모듈은 좋은 응집력을 가져야합니다. 즉, 구성 요소 간의 협력이 높아야합니다.

  • 모듈은 다른 모듈과 낮은 결합을 가져야합니다. 즉, 모듈 간의 상호 작용 또는 상호 의존성이 최소화되어야합니다.

디자인 최적화

분석 모델은 시스템에 대한 논리적 정보를 캡처하는 반면, 설계 모델은 효율적인 정보 액세스를 지원하기 위해 세부 정보를 추가합니다. 설계를 구현하기 전에 구현을보다 효율적으로 만들 수 있도록 최적화해야합니다. 최적화의 목적은 시간, 공간 및 기타 측정 항목 측면에서 비용을 최소화하는 것입니다.

그러나 구현의 용이성, 유지 보수성 및 확장 성 또한 중요한 관심사이므로 설계 최적화는 초과해서는 안됩니다. 완벽하게 최적화 된 디자인이 더 효율적이지만 가독성과 재사용 가능성이 떨어지는 경우가 종종 있습니다. 따라서 디자이너는 둘 사이의 균형을 유지해야합니다.

설계 최적화를 위해 수행 할 수있는 다양한 작업은 다음과 같습니다.

• 중복 연결 추가
• 사용할 수없는 연결 생략
• 알고리즘 최적화
• 복잡한 표현식의 재 계산을 방지하기 위해 파생 된 속성 저장

중복 연결 추가

설계 최적화 중에 새 연관을 유도하여 액세스 비용을 줄일 수 있는지 확인합니다. 이러한 중복 연결은 정보를 추가하지 않을 수 있지만 전체 모델의 효율성을 높일 수 있습니다.

사용할 수없는 연결 생략

너무 많은 연결이 있으면 시스템을 해독 할 수 없게되어 시스템의 전체 효율성이 저하 될 수 있습니다. 따라서 최적화 중에 사용할 수없는 모든 연결이 제거됩니다.

알고리즘 최적화

객체 지향 시스템에서 데이터 구조 및 알고리즘의 최적화는 협업 방식으로 수행됩니다. 클래스 디자인이 제자리에 있으면 작업과 알고리즘을 최적화해야합니다.

알고리즘 최적화는-

• 계산 작업 순서 재정렬
• 기능 모델에 배치 된 루프 실행 순서의 반전
• 알고리즘 내에서 데드 패스 제거

파생 속성 저장 및 저장

파생 속성은 값이 다른 속성 (기본 속성)의 함수로 계산되는 속성입니다. 파생 된 속성 값을 필요할 때마다 재 계산하는 것은 시간이 많이 걸리는 절차입니다. 이를 방지하기 위해 값을 계산하여 계산 된 형식으로 저장할 수 있습니다.

그러나 이것은 업데이트 이상, 즉 파생 된 속성의 값에 대응하는 변경없이 기본 속성의 값의 변경을 야기 할 수 있습니다. 이를 방지하기 위해 다음 단계가 수행됩니다.

• 기본 속성 값이 업데이트 될 때마다 파생 된 속성도 다시 계산됩니다.

• 파생 된 모든 속성은 각 업데이트 이후가 아니라 그룹에서 주기적으로 다시 계산되고 업데이트됩니다.

설계 문서

문서화는 소프트웨어 제작 절차를 기록하는 소프트웨어 개발 프로세스의 필수 부분입니다. 설계를 다른 사람에게 전송하기위한 중요하지 않은 소프트웨어 시스템에 대해 설계 결정을 문서화해야합니다.

사용 영역

보조 제품이지만 특히 다음 영역에서 좋은 문서화는 필수입니다.

• 여러 개발자가 개발중인 소프트웨어를 설계 할 때
• 반복적 인 소프트웨어 개발 전략에서
• 소프트웨어 프로젝트의 후속 버전 개발
• 소프트웨어 평가 용
• 테스트 조건 및 영역 찾기
• 소프트웨어 유지 관리를 위해.

내용

유익한 문서에는 기본적으로 다음 내용이 포함되어야합니다.

• High–level system architecture − 공정 다이어그램 및 모듈 다이어그램

• Key abstractions and mechanisms − 클래스 다이어그램 및 개체 다이어그램.

• Scenarios that illustrate the behavior of the main aspects − 행동 다이어그램

풍모

좋은 문서의 특징은-

• 간결하고 동시에 모호하지 않고 일관성 있고 완전합니다.

• 시스템의 요구 사항 사양에 따라 추적 가능

• Well-structured

• 설명이 아닌 다이어그램

객체 지향 설계를 구현하려면 일반적으로 표준 객체 지향 프로그래밍 언어 (OOPL)를 사용하거나 객체 설계를 데이터베이스에 매핑합니다. 대부분의 경우 둘 다 포함됩니다.

프로그래밍 언어를 사용한 구현

일반적으로 개체 디자인을 코드로 변환하는 작업은 간단한 프로세스입니다. C ++, Java, Smalltalk, C # 및 Python과 같은 모든 객체 지향 프로그래밍 언어에는 클래스 표현을위한 규정이 포함되어 있습니다. 이 장에서는 C ++를 사용하여 개념을 예시합니다.

다음 그림은 C ++를 사용하는 Circle 클래스의 표현을 보여줍니다.

연결 구현

대부분의 프로그래밍 언어는 연결을 직접 구현하는 구조를 제공하지 않습니다. 따라서 연관성을 구현하는 작업에는 상당한 생각이 필요합니다.

연관은 단방향 또는 양방향 일 수 있습니다. 게다가, 각 연관은 일대일, 일대 다 또는 다 대다 일 수 있습니다.

단방향 연결

단방향 연결을 구현하려면 단 방향성이 유지되도록주의해야합니다. 다른 다중성에 대한 구현은 다음과 같습니다.

• Optional Associations− 여기에서 참여하는 객체간에 링크가있을 수도 있고 없을 수도 있습니다. 예를 들어, 아래 그림의 고객과 현재 계정 간의 연결에서 고객은 현재 계정이있을 수도 있고 없을 수도 있습니다.

구현을 위해 현재 계정의 개체는 NULL 일 수있는 Customer의 속성으로 포함됩니다. C ++를 사용한 구현-

class Customer {
   private:
   // attributes
   Current_Account c; //an object of Current_Account as attribute
   
   public:  

   Customer() {
      c = NULL; 
   } // assign c as NULL

   Current_Account getCurrAc() {
      return c;
   }
   
   void setCurrAc( Current_Account myacc) {
      c = myacc;
   }

   void removeAcc() {  
      c = NULL;
   } 
};

• One–to–one Associations− 여기에서 클래스의 한 인스턴스는 관련 클래스의 정확히 한 인스턴스와 관련됩니다. 예를 들어, 부서와 관리자는 아래 그림과 같이 일대일 연관성을 갖습니다.

이는 NULL이 아니어야하는 Manager의 개체 인 Department를 포함하여 구현됩니다. C ++를 사용한 구현-

class Department {
   private:
   // attributes
   Manager mgr; //an object of Manager as attribute
   
   public:  
   Department (/*parameters*/, Manager m) { //m is not NULL   
      // assign parameters to variables
      mgr = m;
   } 

   Manager getMgr() {  
      return mgr;  
   }    
};

• One–to–many Associations− 여기서 한 클래스의 인스턴스는 관련 클래스의 둘 이상의 인스턴스와 관련됩니다. 예를 들어, 다음 그림에서 직원과 부양 가족 간의 연관을 고려하십시오.

이는 Employee 클래스에 Dependents 목록을 포함하여 구현됩니다. C ++ STL 목록 컨테이너를 사용한 구현-

class Employee {
   private:
   char * deptName;
   list <Dependent> dep; //a list of Dependents as attribute

   public:  
   void addDependent ( Dependent d) { 
      dep.push_back(d); 
   } // adds an employee to the department

   void removeDeoendent( Dependent d) { 
      int index = find ( d, dep );
      // find() function returns the index of d in list dep
      dep.erase(index);
   }               
};

양방향 연결

양방향 연결을 구현하려면 양방향 링크를 유지해야합니다.

• Optional or one–to–one Associations − 아래 그림과 같이 일대일 양방향 연관성을 갖는 프로젝트와 프로젝트 관리자 간의 관계를 고려하십시오.

C ++를 사용한 구현-

Class Project {
   private:
   // attributes
   Project_Manager pmgr; 
   public:  
   void setManager ( Project_Manager pm);       
   Project_Manager changeManager();   
};

class Project_Manager {
   private:
   // attributes
   Project pj; 

   public:  
   void setProject(Project p);       
   Project removeProject();   
};

• One–to–many Associations − 아래 그림과 같이 일대 다 연관성을 갖는 부서와 직원 간의 관계를 고려하십시오.

C ++ STL 목록 컨테이너를 사용한 구현

class Department {
   private:
   char * deptName;
   list <Employee> emp; //a list of Employees as attribute

   public:  
   void addEmployee ( Employee e) { 
      emp.push_back(e); 
   } // adds an employee to the department

   void removeEmployee( Employee e) { 
      int index = find ( e, emp );
      // find function returns the index of e in list emp
      emp.erase(index);
   }               
};

class Employee {
   private:
   //attributes
   Department d;

   public:
   void addDept();
   void removeDept();
};

연결을 클래스로 구현

연관에 일부 속성이 연관되어 있으면 별도의 클래스를 사용하여 구현해야합니다. 예를 들어, 아래 그림에 표시된 것처럼 Employee와 Project 간의 일대일 연관을 고려하십시오.

C ++를 사용한 WorksOn 구현

class WorksOn {
   private:
   Employee e; 
   Project p;
   Hours h;
   char * date;

   public:
   // class methods
};

제약 사항 구현

클래스의 제약 조건은 속성이 취할 수있는 값의 범위와 유형을 제한합니다. 제약 조건을 구현하기 위해 객체가 클래스에서 인스턴스화 될 때 유효한 기본값이 속성에 할당됩니다. 런타임시 값이 변경 될 때마다 값이 유효한지 여부를 확인합니다. 유효하지 않은 값은 예외 처리 루틴 또는 기타 메소드에 의해 처리 될 수 있습니다.

Example

나이가 18에서 60 사이의 값을 가질 수있는 속성 인 Employee 클래스를 고려하십시오. 다음 C ++ 코드는이를 통합합니다.

class Employee {
   private: char * name;
   int age;
   // other attributes

   public:
   Employee() {                 // default constructor   
      strcpy(name, "");
      age = 18;                // default value
   }
 
   class AgeError {};          // Exception class
   void changeAge( int a) {    // method that changes age

      if ( a < 18 || a > 60 )  // check for invalid condition
      throw AgeError();        // throw exception
      age = a;			
   }
};

상태 차트 구현

상태 차트 다이어그램에서 상태를 구현하는 두 가지 대체 구현 전략이 있습니다.

클래스 내 열거

이 접근 방식에서 상태는 데이터 멤버 (또는 데이터 멤버 집합)의 다른 값으로 표시됩니다. 값은 클래스 내의 열거에 의해 명시 적으로 정의됩니다. 전환은 관련 데이터 멤버의 값을 변경하는 멤버 함수로 표시됩니다.

일반화 계층의 클래스 배열

이 접근 방식에서 상태는 공통 포인터 변수에 의해 참조 될 수있는 방식으로 일반화 계층 구조로 배열됩니다. 다음 그림은 상태 차트 다이어그램에서 일반화 계층으로의 변환을 보여줍니다.

데이터베이스 시스템에 대한 개체 매핑

개체의 지속성

객체 지향 시스템 개발의 중요한 측면은 데이터의 지속성입니다. 지속성을 통해 개체는 개체를 만든 프로그램보다 수명이 더 깁니다. 영구 데이터는 필요할 때 다시로드 할 수있는 보조 저장 매체에 저장됩니다.

RDBMS 개요

데이터베이스는 관련 데이터의 정렬 된 모음입니다.

데이터베이스 관리 시스템 (DBMS)은 데이터베이스에서 데이터를 정의, 생성, 저장, 조작, 검색, 공유 및 제거하는 프로세스를 용이하게하는 소프트웨어 모음입니다.

관계형 데이터베이스 관리 시스템 (RDBMS)에서 데이터는 관계 또는 테이블로 저장됩니다. 여기서 각 열 또는 필드는 속성을 나타내고 각 행 또는 튜플은 인스턴스의 레코드를 나타냅니다.

각 행은 선택한 최소 속성 집합으로 고유하게 식별됩니다. primary key.

ㅏ foreign key 관련 테이블의 기본 키인 속성입니다.

RDBMS에서 클래스를 테이블로 표시

클래스를 데이터베이스 테이블에 매핑하기 위해 각 속성은 테이블의 필드로 표시됩니다. 기존 속성이 기본 키로 지정되거나 별도의 ID 필드가 기본 키로 추가됩니다. 클래스는 요구 사항에 따라 수평 또는 수직으로 분할 될 수 있습니다.

예를 들어 Circle 클래스는 아래 그림과 같이 테이블로 변환 할 수 있습니다.

Schema for Circle Table: CIRCLE(CID, X_COORD, Y_COORD, RADIUS, COLOR)
Creating a Table Circle using SQL command:
CREATE TABLE CIRCLE (   
   CID	VARCHAR2(4) PRIMARY KEY,
   X_COORD INTEGER NOT NULL,
   Y_COORD INTEGER NOT NULL,
   Z_COORD INTEGER NOT NULL,
   COLOR 
);

데이터베이스 테이블에 연결 매핑

일대일 연결

1 : 1 연결을 구현하기 위해 한 테이블의 기본 키가 다른 테이블의 외래 키로 할당됩니다. 예를 들어, 부서와 관리자 간의 연관성을 고려하십시오.

테이블을 만드는 SQL 명령

CREATE TABLE DEPARTMENT ( 
   DEPT_ID INTEGER PRIMARY KEY,
   DNAME VARCHAR2(30) NOT NULL,
   LOCATION VARCHAR2(20),
   EMPID INTEGER REFERENCES MANAGER 
);

CREATE TABLE MANAGER ( 
   EMPID INTEGER PRIMARY KEY,
   ENAME VARCHAR2(50) NOT NULL,
   ADDRESS VARCHAR2(70),
);

일대 다 연결

1 : N 연관을 구현하기 위해 연관의 1- 측에있는 테이블의 기본 키가 연관의 N 측에있는 테이블의 외래 키로 할당됩니다. 예를 들어, 부서와 직원 간의 연관성을 고려하십시오.

테이블을 만드는 SQL 명령

CREATE TABLE DEPARTMENT ( 
   DEPT_ID INTEGER PRIMARY KEY,
   DNAME VARCHAR2(30) NOT NULL,
   LOCATION VARCHAR2(20),
);

CREATE TABLE EMPLOYEE ( 
   EMPID INTEGER PRIMARY KEY,
   ENAME VARCHAR2(50) NOT NULL,
   ADDRESS VARCHAR2(70),
   D_ID INTEGER REFERENCES DEPARTMENT
);

다 대다 연결

M : N 연관을 구현하기 위해 연관을 나타내는 새 관계가 작성됩니다. 예를 들어, Employee와 Project 사이의 다음 연관을 고려하십시오.

Schema for Works_On Table − WORKS_ON (EMPID, PID, HOURS, START_DATE)

SQL command to create Works_On association − TABLE WORKS_ON 생성

( 
   EMPID INTEGER,
   PID INTEGER, 
   HOURS INTEGER,
   START_DATE DATE,
   PRIMARY KEY (EMPID, PID),
   FOREIGN KEY (EMPID) REFERENCES EMPLOYEE,
   FOREIGN KEY (PID) REFERENCES PROJECT 
);

상속을 테이블에 매핑

상속을 매핑하기 위해 기본 테이블의 기본 키가 파생 테이블의 기본 키와 외래 키로 할당됩니다.

Example

프로그램 코드가 작성되면 테스트를 거쳐 모든 오류를 감지하고 처리해야합니다. 테스트 목적으로 여러 체계가 사용됩니다.

또 다른 중요한 측면은 프로그램이 목적에 부합하는지 여부를 확인하는 프로그램의 목적 적합성입니다. 적합성은 소프트웨어 품질을 정의합니다.

객체 지향 시스템 테스트

테스트는 소프트웨어 개발 중 지속적인 활동입니다. 객체 지향 시스템에서 테스트는 단위 테스트, 하위 시스템 테스트 및 시스템 테스트의 세 가지 수준을 포함합니다.

단위 테스트

단위 테스트에서는 개별 클래스가 테스트됩니다. 클래스 속성이 디자인에 따라 구현되었는지 여부와 메서드 및 인터페이스에 오류가 없는지 여부를 확인할 수 있습니다. 단위 테스트는 구조를 구현하는 애플리케이션 엔지니어의 책임입니다.

하위 시스템 테스트

여기에는 특정 모듈 또는 하위 시스템 테스트가 포함되며 하위 시스템 책임자의 책임입니다. 여기에는 하위 시스템 내부의 연관성 및 하위 시스템과 외부의 상호 작용 테스트가 포함됩니다. 하위 시스템 테스트는 새로 출시 된 각 하위 시스템 버전에 대한 회귀 테스트로 사용할 수 있습니다.

시스템 테스트

시스템 테스트에는 전체 시스템 테스트가 포함되며 품질 보증 팀의 책임입니다. 팀은 새 릴리스를 조립할 때 종종 시스템 테스트를 회귀 테스트로 사용합니다.

객체 지향 테스트 기법

그레이 박스 테스트

객체 지향 프로그램을 테스트하기 위해 디자인 할 수있는 다양한 유형의 테스트 케이스를 그레이 박스 테스트 케이스라고합니다. 회색 상자 테스트의 중요한 유형 중 일부는 다음과 같습니다.

• State model based testing − 이것은 상태 커버리지, 상태 전환 커버리지 및 상태 전환 경로 커버리지를 포함합니다.

• Use case based testing − 각 사용 사례의 각 시나리오가 테스트됩니다.

• Class diagram based testing − 각 클래스, 파생 클래스, 연관 및 집계가 테스트됩니다.

• Sequence diagram based testing − 시퀀스 다이어그램의 메시지에있는 방법이 테스트됩니다.

하위 시스템 테스트를위한 기술

서브 시스템 테스트의 두 가지 주요 접근 방식은 다음과 같습니다.

• Thread based testing − 하위 시스템에서 단일 사용 사례를 실현하는 데 필요한 모든 클래스가 통합되고 테스트됩니다.

• Use based testing− 각 계층 구조 수준에서 모듈의 인터페이스와 서비스가 테스트됩니다. 테스트는 개별 클래스에서 클래스로 구성된 작은 모듈, 점진적으로 더 큰 모듈, 마지막으로 모든 주요 하위 시스템으로 시작됩니다.

시스템 테스트 범주

• Alpha testing − 이는 소프트웨어를 개발하는 조직 내 테스트 팀에서 수행합니다.

• Beta testing − 이는 일부 협력 고객 그룹에 의해 수행됩니다.

• Acceptance testing − 이는 인도 물을 수락하기 전에 고객이 수행합니다.

소프트웨어 품질 보증

소프트웨어 품질

Schulmeyer와 McManus는 소프트웨어 품질을 "전체 소프트웨어 제품 사용에 대한 적합성"으로 정의했습니다. 양질의 소프트웨어는해야 할 일을 정확히 수행하며 사용자가 정한 요구 사항 사양의 만족도 측면에서 해석됩니다.

품질 보증

소프트웨어 품질 보증은 소프트웨어 제품이 사용하기에 적합한 정도를 결정하는 방법론입니다. 소프트웨어 품질을 결정하기 위해 포함 된 활동은 다음과 같습니다.

• Auditing
• 표준 및 지침 개발
• 보고서 작성
• 품질 시스템 검토

품질 요인

• Correctness − 정확성은 소프트웨어 요구 사항이 적절하게 충족되는지 여부를 결정합니다.

• Usability − 사용성은 다른 범주의 사용자 (초보자, 비 기술자 및 전문가)가 소프트웨어를 사용할 수 있는지 여부를 결정합니다.

• Portability − 이식성은 소프트웨어가 다른 하드웨어 장치가있는 다른 플랫폼에서 작동 할 수 있는지 여부를 결정합니다.

• Maintainability − 유지 보수성은 오류를 수정하고 모듈을 업데이트 할 수있는 용이성을 결정합니다.

• Reusability − 재사용 성은 모듈과 클래스를 다른 소프트웨어 제품 개발에 재사용 할 수 있는지 여부를 결정합니다.

객체 지향 메트릭

지표는 크게 프로젝트 지표, 제품 지표 및 프로세스 지표의 세 가지 범주로 분류 할 수 있습니다.

프로젝트 지표

프로젝트 지표를 통해 소프트웨어 프로젝트 관리자는 진행중인 프로젝트의 상태와 성과를 평가할 수 있습니다. 다음 메트릭은 객체 지향 소프트웨어 프로젝트에 적합합니다.

• 시나리오 스크립트 수
• 키 클래스 수
• 지원 클래스 수
• 서브 시스템 수

제품 지표

제품 메트릭은 개발 된 소프트웨어 제품의 특성을 측정합니다. 객체 지향 시스템에 적합한 제품 메트릭은 다음과 같습니다.

• Methods per Class− 클래스의 복잡성을 결정합니다. 클래스의 모든 메서드가 똑같이 복잡하다고 가정하면 메서드가 더 많은 클래스가 더 복잡하므로 오류에 더 취약합니다.

• Inheritance Structure− 여러 개의 작은 상속 격자가있는 시스템은 하나의 큰 상속 격자가있는 시스템보다 더 잘 구조화됩니다. 일반적으로 상속 트리의 수준은 7 (± 2) 개를 넘지 않아야하며 트리는 균형을 이루어야합니다.

• Coupling and Cohesion − 결합이 낮고 응집력이 높은 모듈은 재사용 성과 유지 보수성이 더 높기 때문에 더 나은 설계로 간주됩니다.

• Response for a Class − 클래스의 인스턴스에 의해 호출되는 메서드의 효율성을 측정합니다.

프로세스 메트릭

프로세스 메트릭은 프로세스가 수행되는 방식을 측정하는 데 도움이됩니다. 오랜 기간 동안 모든 프로젝트에서 수집됩니다. 장기적인 소프트웨어 프로세스 개선을위한 지표로 사용됩니다. 일부 프로세스 메트릭은 다음과 같습니다.

• KLOC 수 (Kilo Lines of Code)
• 결함 제거 효율
• 테스트 중 감지 된 평균 실패 수
• KLOC 당 잠재 결함 수