OO Methodology Overview ACM

2 Table of Contents What is Object-Orientation –Programming Paradigm Shift –Programming Langauge Evolution –Principles of Object-Orientation –Basic Elements of Object-Orientation –History of Object-Orientation –Benefits and Limitations Object-Oriented Methods –What is Method –Method War –UML –Software Development Lifecycles –Rational Unified Process Object-Oriented Analysis/Design Design Patterns and Frameworks Beyond Objects

3 Programming Paradigm Shift Programming Paradigm –a way of thinking and understanding real world domain problems and organizing programs to solve the problems on the basis of some conceptual model of programming Various Programming Paradigms –Procedure-Oriented –Object-Oriented –Logic-Oriented –Function-Oriented –Rule-Based –Constraint-Oriented Paradigm Shift

4 Programming Language Evolution 1950s Modular ProgrammingFORTRAN COBOL 1970s Structured ProgrammingALGOL PASCAL, C 1980s Object-Oriented Programming SMALTALK C++, CLOS ADA 1990s Distributed ProgrammingJAVA,Web CORBA DCOM 2000s Component-Oriented Programming CORBA CCM.NET EJB Ours??

5 Basic Elements of Object-Orientation Object Class Message Passing Inheritance Subtyping Dynamic Binding Polymorphism

6 Principles of Object-Orientation abstraction encapsulation modularity hierarchy

7 Abstraction Abstraction is the process of identifying the important or essential qualities or properties of the entity being modeled, hiding inessential detail. Focuses on the outside view of an object Division of behavior from its implementation Contract defines –responsibility –protocol Example void push(int) int pop() doesn’t care if stack container is implemented in a form of array or linked list

8 Encapsulation Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior - Grady Booch Whereas abstraction helps people to think about what they are doing, encapsulation allows program changes to be reliably made with limited effort Abstraction focuses upon the observable behavior of an object, whereas encapsulation focuses upon the implementation that give rise to this behavior Abstraction and encapsulation are complementary concepts Example : stack void push (int) int pop() int s[10]; int top = 0; void push(int a) {... } int pop() {... } The implementation is hidden and the clients can not access directly the implementation

9 Modularity Modularity is the peroperty of a system that has been decomposed into a set of cohesive and loosely coupled modules - Grady Booch Modularization consists of dividing a program into modules which can be compiled separately, but which have connections with other modules. –Liskov To reduce complexity To enhance comprehesion of program To promote reusable components Two levels of modularity in object model –A class itself is a module –Package of abstraction (physical units) Examples In C++ : file In Modula-2 : module In Ada : package In Java : package How to decompose a system into modules is difficult Abstraction, encapsulation and modularity are synergistic

10 Hierarchy Hierarchy is a ranking or ordering of abstractions -Grady Booch Hierarchy is a structure of domain knowledge Three kinds of Hierarchy –(Implementation) Inheritance Hierarchy –Type Hierarchy (is-a hierarchy) –Aggregation (part-of hierarchy) Sharing behaviors (code reuse) Checking conformity Simplify understanding of problem

11 History of Object-Orientation Phase I s (The Age of Invention) –Simula - concepts of object, class, inheritance –Alan Kay ’s Dynabook (Xerox Park) –Smalltalk (72-80) - object-oriented –CLU, Modula-2, Mesa, Euclid, Gypsy - data abstraction –ER model –AI : Frames, Semantic Networks Phase II s (The Age of Confusion) –Extensions to traditional languages –C-based : C++, Objective-C –Lisp-based : LOOPS, Flavors, CLOS –Logic-based –Pascal-based –New languages : Eiffel, Actor Phase III -1990s (The Age of Ripening) –Focus on Design and Analysis –Object-Oriented Database –Standardization - OMG, CORBA –Distributed and Open Systems –Commercial Applications Phase IV – 2000s(The Age of Process Maturity) –Focus on architecutre & patterns –Mature OO development processes –Migration to component-based systems and wrapped legacy systems –Increased attention to business modelling and requirement engineering –Shifted emphasis from C++ to Java and other safer languages

12 Benefits and Limitations Benefits –Lower maintenance cost –Reusability –Extensibility –Scalability –Secure system –Productivity –Quality Problems and Limitation –Designing reusable modules actually adds cost –Management of large libararies –Effienciency –Granularity Units of abstraction, analysis, compilation, distribution, loading, etc. cf. Components

13 Object-Oriented Methods Method and Methodology –a method is a disciplined process for generating a set of models that describe various aspects of a software system –a methodology is a collection of methods applied across the software development life cycle and unified by some general, philosophical approach Method –a set of philosophical principles –a planned procedure by which a specified goal is approached step by step (process) –a process is broken into several phases(activity) –application of a phase produces a model for the phase –modeling techniques and modeling languages –CASE tools Two most essential aspects of Method –Modeling Technique top-down structured modeling information engineering object-oriented modeling –Process Model waterfall prototyping incremental and iterative(e.g. spiral model) Object-Oriented Methods –object-oriented models OOA/OOD Models –creating a new process model or adopting or modifying existing process models

14 Method War Shlaer and Mellor(1988, 1991) Coad and Yourdon(1990,1991) Booch (1991, 1993, 1994) OMT(Rumbaugh, 1991) Martin-Odell(1992) Objectory(Jacobson, 1992) RDD(Wrifs-Brock,1990) –CRC MOSES(Henderson-Sellers, 1994) Syntropy(Cook, 1994) ROOM(Selic, 1994) SOMA(Graham, 1995) Rational Objectory Process(Booch and OMT, 1995) Fusion Method(Coleman, 1994, 1996) OPEN(Graham, 1997) UML(Three amigos, 1997) Rational Unified Process (Three amigos, 1998) Catalysis(D’Souza, 1999)

15 Modeling and Modeling Language What is a Model –a description of some thing –an abstraction of a system – broken into several views each of which describes an aspect of a target system –modeling must investigate requirements for the finished system such as functionality, appearance, performance, reliability, etc. What is a good model –allows different viewers to see different levels of detail at different times –is connected to reality –works well with other models in capturing all of the essential elements of the system Modeling Language –consists of formal notation and rules (syntax, semantics, and pragmatics) –usually a form of visual language –characteristics Accurate or formal Consistent Easy to communicate Easy to change Understandable

16 UML The Unified Modeling Language(UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. Primary Artifacts of the UML –use case diagram : requirement –class diagram: structural –statechart diagram –activity diagram –sequence diagram –collaboration diagram –component diagram –deployment diagram behavioral implementation

17 UML Booch Unified Method 0.8 UML 1.0 OMT OOSE/ Objectory UML 0.9 OOPSLA ´95 WWW - June ´96 Beta version OOPSLA ´96 Submission to OMG, Jan ´97 Documentation Set WWW Spec only Other methods UML 1.1 Submission to OMG, Sept ‘97 OMG Vote, Oct ‘97 UML 1.4 Sep UML 1.2,1.3 ’98~’99 Mar UML 1.5 Present UML 2.0

18 Software Development Process Model Waterfall lifecycle model Requirement Analysis Design Implementation Testing Operation & Maintenance Time Risk

19 Software Development Process Model Iterative and Incremental Process –early mitigation of risks –taking into accounting changing requirements –making tactical changes –facilitating reuse –resulting very robust architecture –learning along the way Management Environment Analysis and Design Deployment Testing Implementation Evaluation Planning Requirement initial planning

20 Rational Unified Process What is the Rational Unified Process –is a software engineering process –is a process product (“software process is a software too”) –is a process framework RUP captures many of the best practices in modern software development –Develop software iteratively –Manage requirements –Use component-based architecture –Visually model software –Continuously verify software quality –Control changes to software Other key features –use-case driven development –process configuration –tools support

21 Rational Unified Process Process Structure : Two Dimensions milestone

22 Rational Unified Process Rational Unified Process 2000 Rational Unified Process 5.5 Rational Unified Process 5.0 Rational Objectory Process 4.1 Rational Objectory Process 4.0 Rational Approach Objectory Process 3.8 Real Time (ROOT) Web-Based Development business engineering Configuration and Change Management Data Engineering UI Design UML 1.3 Requirement College SQA Process UML 1.2 UML 1.1 UML 0.8 Booch MethodOMT

23 Object-Oriented Analysis/Design Analysis emphasizes an investigation of the problem and requirements, rather than a solution. –do the right thing Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation –do the thing right Object-Oriented Analysis –is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain [Booch 94] –emphasizes on finding and describing the objects or concepts in the problem domain for example, in the case of the library information system, some of the concepts include Book, Library, Customer. Object-Oriented Design –Design process is to further refine and formalize the analysis model taking into account of the implementation environment, producing a design model: [Jacobson92] –emphasizes on defining software objects and how they collaborate to fulfill the requirements for example, a Book software object having title attribute and getChapter() method

24 Birds-eye View (using UML) Example : Dice game –a player rolls two die –if the total is seven, they win; otherwise, they lose Define Use Cases (Requirement Capture) –Play a Dice Game : A player picks up ad rolls the dice. If the dice face value total seven, they win; otherwise, they lose. Define a Domain Model (Analysis)

25 Birds-eye View Define Interaction Diagrams (Analysis to Design) Define Design Class Diagrams (Design)

26 Design Patterns and Frameworks Reuse of Designs –Patterns –Frameworks Design pattern –describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution –consists three components 1.Context 2.Problem 3.Solution Gang of Four[GOF95] –creational patterns – 5 patterns –structural patterns – 7 patterns –behavioral patterns – 11 patterns [Buschmann96] –Architectural pattern expresses a fundamental structural organization schema for software systems.(8 patterns) –Design pattern provides a scheme for refining the subsystems or components of a software system, or the relationship between them.(8 patterns) –Idiom is a low-level pattern specific to a programming language(e.g. reference counting for garbage collection in C++)

27 Beyond Objects Distributed Application Middleware Component Based Software Development The Microsoft Way –COM –OLE/ActiveX –COM+ –.NET The Sun Way –Java –JavaBeans –Enterprise Java Beans(EJB) The OMG Way –CORBA –CCM –OMA –MDA (model driven architecture) Web as a Middleware for Distributed Applications –Web Services –XML