1 / 45

Object-Oriented Methods: Analysis, Design & Programming

Object-Oriented Methods: Analysis, Design & Programming. Outline. OOA OOD: UML OOP: C++. Henderson Analysis Design Implementation. OOA - OOD - OOP. Coad/Nicola “Baseball Model”. Outline. Software Development Models Object-Oriented Concepts. UML Bibliography.

latia
Télécharger la présentation

Object-Oriented Methods: Analysis, Design & Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Object-Oriented Methods:Analysis, Design & Programming

  2. Outline • OOA • OOD: UML • OOP: C++

  3. Henderson Analysis Design Implementation OOA - OOD - OOP Coad/Nicola “Baseball Model”

  4. Outline • Software Development Models • Object-Oriented Concepts

  5. UML Bibliography • The Unified Modeling Language User Guide Booch et al, Addison-Wesley • UML Toolkit Hans-Erik Eriksson et al, Wiley • UML in a Nutshell Sinan Si Alhir, O’Reilly

  6. General Bibliography • Design Patterns Erich Gamma et al, Addison-Wesley • Applying UML and Patterns Craig Larman, Prentice-Hall • The Practice of Programming Brian Kernighan et al, Addison-Wesley

  7. C++ References • “C++ for Java Programmers” Mark Allen Weiss, Pearson / Prentice Hall • “C++: How to Program", Deitel & Deitel, Prentice Hall • "C++ Primer” Stanley Lippman, Addison-Wesley • "The C++ Programming Language" Bjarne Stroustrup, Addison-Wesley • "The Annotated C++ Reference Manual“ Bjarne Stroustrup and Margareth Ellis, Addison Wesley

  8. 객체지향개발의 등장배경 객체지향 방법론의 등장 이유는 프로그래머 생산성 향상과 유지보수비용 절감으로 집약된다. 그 이유는 다음과 같다. 1. 객체중심의 모델링이 현실세계를 보다 가깝게 묘사하기 때문에 시스템에 대한 이해가 증진 되기 때문이다 2. 소프트웨어의 재사용성(reusability)의 증가. 3. 그래픽 유저 인터페이스(GUI)와 윈도우 시스템의 등장을 들 수 있다. 4. 모델과 현실간의 자연스러운 대응을 통해 실시간 시스템 개발에 적합하다는 주장도 있다. 5. 객체지향 분석과 설계는 객체지향 프로그래밍을 전제로 성립 가능

  9. Why OO? • OO Approaches in General • OO approaches encourage the use of “modern” SE technology • OO approaches promote and facilitate software reuse • OO approaches facilitate interoperability • When done well, OO approaches produce solutions which closely resemble the original problem

  10. Why OO? • When done well, OO approaches result in software that is easily modified, extended, and maintained • The Overall OO Approach • Traceability improves if an overall OO approach is used • There is a significant reductionin integration problems • The conceptual integrity of both the process and product improves source: Motivation for an Object-Oriented Approach to Software Engineering, Edward Berard The conceptual integrity- means that the system’s separate components work well together as a whole with balance between flexibility, maintainability, efficiency…

  11. The Spiral Software Cycle Traditional Object-Oriented

  12. 붕어빵과 Object 붕어빵 기계와 Class

  13. Object and Class Item B916X5 Bolt 200 0 method ItemID를 출력하라 Description을 출력하라 Quantity를 출력하라 Item을 인도하라 Item을 기록하라 property(변수) ItemID Description Quantity NumberAllocated object class S716X10 Screw 350 300 : main( ){ Item bolt; // 객체생성 bolt.reportprint(const int * quantity); // 생성된 객체로 하여금 메소드를 실행 Item screw; screw.record(const char * itemid); } : class Item{ private: char itemid; char description; unsigned int quantity; unsigned int numallocate; // 클래스의 속성 정의 public; Item( ); ~Item( ); recordprint(const char* itemid); // 메소드 reportprint(const int * quantity); record(const char * itemid); }; *보충설명 : 개개의 객체들은 클래스에 의해 정의되며 객체들을 생성할 수 있는 템플릿을 만들어 준다. 그러므로 객체는 클래스의 인스탄스이다. 또한 클래스는 객체지향 소프트웨어 구축의 근원이 된다.

  14. Objects • concepts, concrete or abstract, with meaning derived from the problem domain “the real world” • promote an understanding of the problem domain • provide a basis for implementation • encapsulation of state (data values) and behavior (operations)

  15. Sound Signal Amplify Signal Play Amplifier Tape Deck Speaker Turn On Turn Off Set Volume Amplify Signal Turn On Turn Off Play Stop Sound Signal 객체의 동작원리 • 객체들은 메시지를 보냄에 의해 서로간에 의사소통을 한다. 서버 객체 클라이언트 객체

  16. 객체의 동작원리 • 객체들은 서비스를 윈하는 객체가 서비스를 제공하는 객체에게 메시지를 보냄으로써 의사 소통을 한다. • 메시지 시그내쳐는 오퍼레이션 시그내쳐에 일치해야 한다. 즉 서비스 제공 객체가 가지고 있는 오퍼레이션에 맞게 메시지를 보내야 한다는 것이다. • 객체는 오퍼레이션이 일치하는지 확인하고 난 뒤 다시 서비스를 원하는 객체 즉, 클라이언트 객체에게 그 결과값을 되돌려준다. 서버 객체 클라이언트 객체 Message: Play Turn On, Turn Off, Play, Pause, Stop 오퍼레이션

  17. 객체의 동작원리 • 메시지, 오퍼레이션, 메소드 간에 용어를 구별해야 한다. Method: Play: start motor start laser position laser detect light signal convert to ... Message: Play Operation: Turn On, Turn Off, Play, Pause, Stop Message객체들 사이의 시그날(신호)이다. Operation 객체에 의해 제공되는 서비스이다. Method 오퍼레이션을 실질적으로 구현한 것이다.

  18. Objects (cont.) • Exhibit behavior by invoking a method in response to a message • 메시지가 접수되면 이를 수행하기 위해 메소드를 호출하여 그 기능 혹은 서비스 제공한다. • instances of classes • an object-oriented program is a collection of autonomous interacting and collaborating objects

  19. Classes • objects sharing common characteristics • dictate the behavior of the object • contain • state: attributes, fields, variables, data member • behavior: functions, methods, function member • access specifiers • instantiation • abstract versus concrete

  20. 3 Pillars of Object-Orientation • Encapsulation • Inheritance • Polymorphism

  21. Encapsulation method Instance Data method method method

  22. Encapsulation “One of the fundamental principles of object technology is that the internals of an object are private to that object and may not be accessed or even examined from outside the object” - David Taylor, Author Business Engineering with Object Technology • Encapsulation means “don’t tell me how you do it; just do it” • An object publishes a public interface that defines how other objects can interact with it

  23. Encapsulation • The two main reasons for controlling access to an objects functions are: • Keep client programmers’ hands off portions they shouldn't touch -- parts that are necessary for the internal machinations of the object but not part of the interface that users need to solve their particular problem • 만약 고객 프로그래머가 다수가 사용하는 라이브러리의 클래스들 내부를 임의대로 변경 조작하면 많은 혼란을 야기 할 수 있다. 오로지 권한이 있는 경우 인터페이스를 통해서 가능하도록 한다. • Allow the library designer to change the internal workings of the structure without worrying about how it will affect the client programmer. • 라이브러리 설계자는 개개의 고객 프로그래머에게 클래스가 어떻게 영향을 미치게 될 것인가 걱정 없이 클래스 내부를 구축할 수 있는 것이다.

  24. Encapsulation • Combination of state and behavior • Implementation details are hidden internally • Internal mechanisms can change while public interfaces remain stable • State may be retrieved using public methods • Behavior consists of methods activated by receipt of messages

  25. Encapsulation • Java uses three explicit keywords and one implied keyword to set the boundaries in a class: • public • private • Protected (상속받은클래스에서 참조) • implied ‘friendly’

  26. Inheritance Inheritance is the mechanism that allows you to create new child classes -- known as subclasses or derived classes -- from existing parent classes • Child classes inherit their parent’s methods and data structures Children classes can enhance the behavior of their parents. And if parental behavior is enhanced, it is to the benefit of the children. - Steve Jobs

  27. Inheritance • You can add new methods to a child’s class or override (modify) inherited methods to define new class behaviors • You use inheritance to extend objects; it means everything in that object plus ...

  28. Inheritance • organization of classes into a hierarchical inheritance tree • data and behavior associated with classeshigher in the tree are accessible to those classes lower in the tree • terminology • ancestor/descendant • superclass/subclass • generalization/specialization

  29. Single Inheritance • classes/objects inherit from only one parent • no ambiguity due to name clashes • examples: Java, Smalltalk

  30. Inheritance Diagram generalization specialization

  31. Multiple Inheritance • classes/objects may have more than one parent • ambiguity (name clashes) can occur • allows abstract classes to be more specific in characteristics • examples: C++, Eiffel

  32. Another Inheritance Diagram

  33. Polymorphism • Polymorphism is a fancy way of saying that the same method can do different things, depending on the class that implements it • Objects in different classes receive the same messageyet react in different ways

  34. Polymorphism • polymorphism: many forms • localizes responsibility for behavior • object automatically uses correct implementation for a method • many objects can respond to the same message • minimizes interface parameter passing

  35. Polymorphism Example

  36. 생성자 함수의 다중정의(Overload) main(void){     init a('R');     // 한 개의 매개변수로 객체생성 a.disp(); init b(1, 'H'); // 두 개의 매개변수로 객체생성 b.disp(); } #include <iostream> class  init {     int  id;        char  letter;        public:  init(char c)  {   id=0;  letter=c;  }  // 생성자 함수의 다중정의 init(int i, char c) {   id= i; letter=c;  }             void disp(void) {   printf("%d  %c\n",  id, letter);  } }; 

  37. 3 Pillars of Object-Orientation • Encapsulation Combine data structures and algorithm together and insulate internal code and data from their interface. Easily to be reused. • Inheritance Reusethe code of the parents as is. • Polymorphism Objects of similar type have the same interface. Easily to be reused.

  38. Reuse • Expected Benefits of Reuse • Timeliness • Decreased maintenance effort • Investment • Reliability • Efficiency • Consistency Source B. Meyer, Object-Oriented Software Construction, 1997

  39. Reuse • What Should we Reuse? • Personnel • Designs and Specifications • Design Patterns • Source Code • Abstracted Modules Source B. Meyer, Object-Oriented Software Construction, 1997

  40. Toolkit • A toolkitis a library of reusable classes designed to provide useful, general-purpose functionality. • E.g., Java APIs (awt, util, io, net,etc)

  41. Design Patterns • A pattern is a proven solution to a problem in a context. • Design patterns represent a solutions to problems that arise when developing software within a particular context. i.e Patterns = problems.solution pairs in a context Context (where does this problem occur) Sapana Mehta (CS-6V81)

  42. Relative Percentages A B C D A X 15 35 35 15 D B Y 10 40 30 20 C Z 10 40 30 20 A B C D A=10% B=40% C=30% D=20% Application data Change notification Requests, modifications Observer Pattern [2] CS 406: Design Patterns

  43. framework • A framework embodies a complete design of an application, while a pattern is an outline of a solution to a class of problems. • A framework dictates the architecture of an application and can be customized to get an application. (E.g., Java Applets) • When one uses a framework, one reuses the main body of the framework and writes the code it calls. • When one uses a toolkit, one writes the main body of the application that calls the code in the toolkit. (E.g., Java AWT)

  44. Framework-Based Programming, cont.

  45. The Java API The Java API (Application Program Interface, Application Programming Interface, or Application Programmer interface) consists of numerous classes and interfaces grouped into more than a dozen of packages. You have used classes and interfaces in the java.lang, javax.swing, andjava.util packages.

More Related