ObjectOriented Technology and Development Computer Science Department Faculty

Object-Oriented Technology and Development Computer Science Department, Faculty of Science, Chiang Mai University

Course Objective � The course will provide an in-depth treatment of object-oriented software development, including analysis, design, and programming. The focus will be on the construction of correct, reusable, and efficient software through a systematic application of design by contract. One important design method will be presented in detail, different programming paradigms will be contrasted, and several object-oriented languages (including C++, C#and Java) will be analyzed.

Course Outline � Brief History of Computers � Principle of Object Oriented Technology � Introduction to Object-Oriented � Object Oriented Languages � Object Oriented Programming Concept � Object Oriented Analysis and Design � Unified Modeling Language (UML) � Design Patterns � Frameworks � Development of Object Oriented � Object Oriented Case Tools

A Brief History of Computers Early 'Computers' 3000 BC Abacus invented and used for quick, manual addition and subtraction calculations. 1645 A mechanical adding and subtracting machine called the Pascaline (after Blaise Pascal) invented. 1830 Charles Babbage (the Father of Computers) designed first electronic computer called the Difference Machine. It was never built but today's computers are based on it. 1890 Punched Cards invented to tabulate 1890 census. Punched cards used for computer input throughout 1960's. 1939 4 First vacuum tube calculating machine invented.

A Brief History of Computers 'Modern' Computers: 1943 1946 called 1959 1965 NASA 1975 no 1977 1981 1984 Today 5 First electronic computer built at Bletchley Park for code breaking. First true general purpose, vacuum tube (1 st generation) computer ENIAC invented. First solid state (2 nd generation) computers using transistors. First integrated circuit (3 rd generation) computers developed by for moon landing programme. First 'home computers' - Altair 8800 - no keyboard or monitor and software! Came in kit form. Apple II - fully assembled home computer. Introduction of the IBM PC - the forerunner of most of today's PCs. Apple Macintosh - the forerunner of most of the rest. The PC architecture remains the same - just much faster and cheaper.

ENIAC (Electronic Numerical Integrator and Computer) 1946 6

Types of Computer Supercomputers Very expensive - so fast they have to be cooled by liquid gases such as Helium. Limited to a few large government and business organisations e. g. for long term weather forecasting. Mainframes Cornerstone of large business, data processing where heavy processing and several thousand users must be handled at once e. g. for bank accounts. Minicomputers A multiuser computer which can handle up to 300 users. In the 1970 s and 1980 s used by medium sized businesses and organisations that could not afford mainframes. Now virtually extinct. Microcomputers The smallest, least expensive and most popular computers - often called desktop computers or personal computers (PCs). Based on Intel (8088, 80286, 80386, 80486, Pentium II and Pentium III) or compatible (AMD Athlon, Duron etc) chips. 7

Generations of Programming Language � First Generation � Second Generation � Third Generation � Fourth Generation (4 th GL) 8

The Nature of Software. . . � Software � Hard to understand development effort � Software � Cost � in � The is easy to reproduce is in its development other engineering products, manufacturing is the costly stage industry is labor-intensive � Hard 9 is intangible to automate

The Nature of Software. . . � Untrained � Quality � Software � People problems are hard to notice is easy to modify make changes without fully understanding it � Software � It people can hack something together does not ‘wear out’ deteriorates by having its design changed: � erroneously, or � in ways that were not anticipated, thus making it complex 10

The Nature of Software � Conclusions � Much software has poor design and is getting worse � Demand for software is high and rising � We are in a perpetual ‘software crisis’ � We have to learn to ‘engineer’ software 11

Types of Software. . . � Custom � For a specific customer � Generic � Sold on open market � Often called � COTS (Commercial Off The Shelf) � Shrink-wrapped � Embedded � Built into hardware � Hard to change 12

What is Software Engineering? . . . � The process of solving customers’ problems by the systematic development and evolution of large, highquality software systems within cost, time and other constraints � Solving � This customers’ problems is the goal of software engineering � Sometimes the solution is to buy, not build � Adding unnecessary features does not help solve the problem � Software engineers must communicate effectively to identify and understand the problem 13

What is Software Engineering? … � Systematic development and evolution � An engineering process involves applying well understood techniques in a organized and disciplined way � Many well-accepted practices have been formally standardized � e. g. by the IEEE or ISO � Most development work is evolution � Large, high quality software systems � Software engineering techniques are needed because large systems cannot be completely understood by one person � Teamwork and co-ordination are required � Key challenge: Dividing up the work and ensuring that the parts of the system work properly together � The end-product that is produced must be of sufficient quality 14

What is Software Engineering? � Cost, time and other constraints � Finite resources � The benefit must outweigh the cost � Others are competing to do the job cheaper and faster � Inaccurate estimates of cost and time have caused many project failures 15

Software Engineering and the Engineering Profession � The term Software Engineering was coined in 1968 � People began to realize that the principles of engineering should be applied to software development � Engineering � In is a licensed profession order to protect the public � Engineers design artifacts following well accepted practices which involve the application of science, mathematics and economics � Ethical practice is also a key tenet of the profession 16

Stakeholders in Software Engineering � 1. Users �Those who use the software � 2. Customers �Those who pay for the software � 3. Software developers � 4. Development Managers �All four roles can be fulfilled by the same person 17

Software Quality. . . � Usability � Users can learn it and fast and get their job done easily � Efficiency � It doesn’t waste resources such as CPU time and memory � Reliability � It does what it is required to do without failing � Maintainability � It can be easily changed � Reusability � Its parts can be used in other projects, so reprogramming is not needed 18

Software Quality. . . Customer: solves problems at an acceptable cost in terms of money paid and resources used User: easy to learn; efficient to use; helps get work done QUALITY SOFTWARE Developer: easy to design; easy to maintain; easy to reuse its parts 19 Development manager: sells more and pleases customers while costing less to develop and maintain

Software Quality � The different qualities can conflict � Increasing efficiency can reduce maintainability or reusability � Increasing usability can reduce efficiency � Setting objectives for quality is a key engineering activity � You then design to meet the objectives � Avoids ‘over-engineering’ which wastes money � Optimizing � E. g. 20 is also sometimes necessary obtain the highest possible reliability using a fixed budget

Internal Quality Criteria � These: � Characterize aspects of the design of the software � Have an effect on the external quality attributes � E. g. � The amount of commenting of the code � The complexity of the code 21 Chapter 1: Software and Software © Lethbridge/Laganière

Software Engineering Projects � Most projects are evolutionary or maintenance projects, involving work on legacy systems � Corrective projects: fixing defects � Adaptive projects: changing the system in response to changes in � Operating system � Database � Rules and regulations � Enhancement projects: adding new features for users � Reengineering or perfective projects: changing the system internally so it is more maintainable 22

Software Engineering Projects � Projects that involve building on a framework or a set of existing components. � The framework is an application that is missing some important details. � E. g. � Such Specific rules of this organization. projects: � Involve plugging together components that are: Already developed. Provide significant functionality. � Benefit from reusing reliable software. � Provide much of the same freedom to innovate found in green field development. 23

Activities Common to Software Projects. . . � Requirements and specification � Includes � Domain analysis � Defining the problem � Requirements gathering Obtaining input from as many sources as possible � Requirements analysis Organizing the information � Requirements specification 24 Writing detailed instructions about how the software should behave

Activities Common to Software Projects. . . � Design � Deciding how the requirements should be implemented, using the available technology � Includes: � Systems engineering: Deciding what should be in hardware and what in software � Software architecture: Dividing the system into subsystems and deciding how the subsystems will interact � Detailed design of the internals of a subsystem � User interface design � Design of databases 25

Activities Common to Software Projects � Modeling � Creating representations of the domain or the software � Use case modeling � Structural modeling � Dynamic and behavioral modeling � Programming � Quality assurance � Reviews and inspections � Testing � Deployment � Managing 26 the process Chapter 1: Software and Software © Lethbridge/Laganière

Software Development Processes � 1. Understanding the customer and the user � 2. Basing development on solid principles and reusable technology � 3. Object orientation � 4. Visual modeling using UML � 5. Evaluation of alternatives � 6. Iterative development � 7. Communicating effectively using documentation � 8. Risk management in all SE activities 27

Difficulties and Risks in Software Engineering � Complexity and large numbers of details � Uncertainty about technology � Uncertainty about requirements � Uncertainty about software engineering skills � Constant change � Deterioration of software design � Political risks 28

Object-Oriented Language Development

Object-Oriented Language Development � Simula I 1961 -64. Compilers from 1965 � Simula 67 1967. Compilers from 1969 - 70 � DELTA 1973 -75. Not compilable description language � Smalltalk, Lisp-based languages From mid-1970 s on � C++, Eiffel From 1980 s on � BETA Research from 1976. Experimental compiler 1983. Industrial compilers late 1980 s � Java Mid 1990 s. Internet oriented

Main Application Areas � Simulation From 1965 on � General Programming From 1965 on � Abstract Data. Types, Monitors From early 1970 s on � Structured Programming Book appearing in 1973 � VSLI Design From the mid-seventies on � Workstation Environments, Incremental Computing Smalltalk versions 1972 -76 -80 � Reusable Software Modules Early work from 1967 on, much work from ca. 1980 � System Development From early 1990 s on � Web Applications from mid-nineties on

Brief History of SIMULA I (1962 -65) and Simula 67 (1967) are the two first object-oriented languages. Simula 67 introduced most of the key concepts of object-oriented programming: both objects and classes, subclasses (usually referred to as inheritance) and virtual procedures, combined with safe referencing and mechanisms for bringing into a program collections of program structures described under a common class heading (prefixed blocks). The Simula languages were developed at the Norwegian Computing Center, Oslo, Norway by Ole-Johan Dahl and Kristen Nygaard's work in Operational Research in the 1950 s and early 1960 s created the need for precise tools for the description and simulation of complex man-machine systems. In 1961 the idea emerged for developing a language that both could be used for system description (for people) and for system prescription (as a computer program through a compiler). Such a language had to contain an algorithmic language, and Dahl's knowledge of compilers became essential. The SIMULA I compiler was partially financed by UNIVAC and was ready in January 1965. SIMULA I quickly got a reputation as a simulation programming language, but turned out in addition to posess interesting properties as a general programming language. When the inheritance mechanism was invented in 1967, Simula 67 was developed as a general programming language that also could be specialised for many domains, including system simulation. Simula 67 compilers started to appear for UNIVAC, IBM, Control Data, Burroughs, DEC and other computers in the early 1970 s.

Brief History of SIMULA I (continue) Simula 67 still is being used many places around the world, but its main impact has been through introducing one of the main categories of programming, more generally labelled object-oriented programming. Simula concepts have been important in the discussion of abstract data types and of models for concurrent program execution, starting in the early 1970 s. Simula 67 and modifications of Simula were used in the design of VLSI circuitry (Intel, Caltech, Stanford). Alan Kay's group at Xerox PARC used Simula as a platform for their development of Smalltalk (first language versions in the 1970 s), extending object-oriented programming importantly by the integration of graphical user interfaces and interactive program execution. Bjarne Stroustrup started his development of C++ (in the 1980 s) by bringing the key concepts of Simula into the C programming language. Simula has also inspired much work in the area of program component reuse and the construction of program libraries. In the 1980 s tremendous resources were put behind the ADA language (US Department of Defense) and PROLOG (the Japanese "Fifth Generation Computer Project"), and many believed that ADA and PROLOG would fight for dominance in the 1990 s. Instead object-oriented programming is today (in the late 1990 s) becoming the dominant style for implementing complex programs with large numbers of interacting components. Among the multitude of object-oriented language are Eiffel (B. Meyer) , CLOS (D. Bobrow and G. Kiczales), SELF (D. Ungar and others). In particular the Internet-related Java (developed by Sun) has rapidly become widely used in recent years. BETA (B. Bruun-Kristensen, O. Lehrmann Madsen, B. Møller-Pedersen and K. Nygaard) is a very general object-oriented language in the Simula tradition.

Object-Oriented Programming Language � � � � � Eiffel, a class-based language with multiple inheritance and genericity aimed at the systematic construction of quality software; Simula, the first object-oriented language providing objects, classes, inheritance, polymorphism, dynamic binding and static typing back in 1967; Smalltalk, the language that popularized object-oriented programming; Sather, a simple Eiffel offspring with separate subtyping and inheritance lattices; Modula-3, an object-oriented system programming language; C++, everyone's favorite language to love and hate; Objective-C, a strange mix of C and Smalltalk; Java, the flavor of the day - what Objective-C and C++ could have been 10 years ago; CLOS, Common Lisp Object System; Obliq, a lexically-scoped untyped interpreted language that supports distributed object-oriented computation; Python, an interpreted, interactive, object-oriented programming language; Ada, the well-known ISO language, now with an OO version (Ada 95); Self, a prototype-based language with uniform access to state and behavior; Cecil, a prototype-based language that combines multi-methods with a classless object model, object-based encapsulation, and optional static type checking; Dylan the (abandoned by) Apple dynamic language; Beta, an attempt to mix object-oriented, functional, and procedural programming practices; Agora, a prototype-based language featuring a generalised mixin approach to inheritance. Oz, a higher-order object-oriented concurrent constraint programming language. Emerald, a distributed object-oriented programming language and system providing both process and object mobility on a network of workstations.

Object-Oriented Concept � Object-Oriented software is all about objects � An object is a “black box” which receives and sends messages. � A black box contains � Code – sequences of computer instruction � Data – information which the instructions operates on � All communication between objects is done via messages (The object acts as receiver and sender)

Basic Terminology � Abstraction � Objects � Classes � Attributes � Operations (Messages, Methods) � Generalization / Specialization � Superclass / Subclass � Inheritance � Interface � Encapsulation � Aggregation � Association � Polymorphism � Reusability

Abstraction and Modeling � Analysis is modeling the real world. � The representation of the real world is necessary to understand it. � Intentionally imperfect representation of the real world. � Modeling is a tool for coping with problems of largeness (Tom De. Marco). � Multiple ways of representation (e. g. , Map). � No single model can address all aspects and any that try will fail. � Reusable thing must be abstract.

Modeling and Map Representation

Comparison OO with Traditional Concept � Traditional programming language : C, Pascal, Fortran, Cobol, Modular, Basic � They are written with Functions and Structures (and normally are not connected) � Functions – units of code � Structure – units of data

Bicycle Object � Software objects are conceptually similar to real-world objects: state and related behavior. � An object stores its state in fields (variables in some programming languages) and exposes its behavior through methods (functions in some programming languages). � Methods operate on an object's internal state and serve as the primary mechanism for object-to-object communication. Hiding internal state and requiring all interaction to be performed through an object's methods is known as data encapsulation — a fundamental principle of object-oriented programming

Benefits of Object Concepts � Modularity: The source code for an object can be written and maintained independently of the source code for other objects. Once created, an object can be easily passed around inside the system. � Information-hiding: By interacting only with an object's methods, the details of its internal implementation remain hidden from the outside world. � Code re-use: If an object already exists (perhaps written by another software developer), you can use that object in your program. This allows specialists to implement/test/debug complex, task-specific objects, which you can then trust to run in your own code. � Pluggability and debugging ease: If a particular object turns out to be problematic, you can simply remove it from your application and plug in a different object as its replacement. This is analogous to fixing mechanical problems in the real world. If a bolt breaks, you replace it, not the entire machine.

Understanding basic terminology � Object-Oriented Technology introduces new way of thinking of software design, analysis and programming � For examples, objects, classes, inheritance, polymorphism (information hiding), interfaces, and packages

What is Object? � An object is a software bundle of related state and behavior. Software objects are often used to model the real-world objects that you find in everyday life. This lesson explains how state and behavior are represented within an object, introduces the concept of data encapsulation, and explains the benefits of designing your software in this manner.

What is Class? � A class is a blueprint or prototype from which objects are created. This section defines a class that models the state and behavior of a real-world object. It intentionally focuses on the basics, showing how even a simple class can cleanly model state and behavior. � In object-oriented terms, we say that your bicycle is an instance of the class of objects known as bicycles. A class is the blueprint from which individual objects are created.

Class Attributes � An object can best be understood by first examining its static structure. � Each object has particular properties, called attributes. � The values of an object represent its states that change over time.

Class Operation � An operation is a behaviour of an object. � An operation is a function or transformation that may be applied to or by objects in a class. � It is available for all instances of the class. � It need not be unique among classes - more than one class may have the same operation. � An operation may have arguments in addition to its target object. e. g. , 3+5

Example of Operations � � � � Catch Throw Fumble Inflate Bunt Tag someone Pitch Bounce Kick Hand-off Tee Down Catch Throw Drop Hit

Method Implementation � A method is the implementation of an operation for a class. � Both footballs and baseballs can be caught or thrown. � "Catch" for the football class is different from the baseball class. � Each method may be implemented by a different piece of code, yet represents the same operation. � Arguments of the operation do not affect the choice of method. � The method depends only on the class of the target object. � When an operation has method on several classes, it is important that the methods all have the same signature : the number and types of arguments, type of result value.

Message Passing � Operations declared in objects external interface. � An object send a message by which the receiving object selects the appropriate operation to be invoked. � The receiver of the message determines how the manipulation is to be performed. � The receiver describes what the sender of the message what to happen but not how it should happen. � This is consistent with the principles of abstraction and information hiding.

Bicycle Class

Classification � Objects with the same structure (attributes) and behaviour (operations) can be grouped together into a class. � An object is an instance of its class. � A class may contain one or more objects. � Every instance in a class have the same operation. � The value of the attributes may not be the same for each instance. For Example, Bicycle

Design Principles of OOP Three main design principles of Object-Oriented Programming(OOP): �Encapsulation �Polymorphism �Inheritance

What is Polymorphism? � Polymorphism—the same word or phrase can be mean different things in different contexts � Analogy: in English, bank can mean side of a river or a place to put money � In Java, two or more classes could each have a method called output � Each output method would do the right thing for the class that it was in. � One output might display a number whereas a different one might display a name.

What is Inheritance? � Inheritance—a way of organizing classes � Inheritance provides a powerful and natural mechanism for organizing and structuring your software. This section explains how classes inherit state and behavior from their superclasses, and explains how to derive one class from another using the simple syntax provided by the Java programming language. �Term comes from inheritance of traits like eye color, hair color, and so on. �Classes with properties in common can be grouped so that their common properties are only defined once.

Generalization and Specialization � Generalization Base : Suppress the differences among several classes, identify their common features, and generalize them into a single superclass of which the original classes are subclasses. � Establish additional relationship (IS_A) between classes. � A class is refined into subclasses that inherit the attributes and operations of the superclass - this process is called specialization.

A hierarchy of bicycle classes class Mountain. Bike extends Bicycle { // new fields and methods defining a mountain bike would go here }

An Inheritance Hierarchy Vehicle Automobile Sedan Motorcycle Sports Car Luxury Bus School Bus What properties does each vehicle inherit from the types of vehicles above it in the diagram?

When to Inherits? � A mechanism for expressing similarity among classes. � Simply definition of classes similar to one previously defined. � Sharing of common features among classes using generalization. � Each subclass inherits the attributes and operations of its superclasses, all the way up to the hierarchy of classes. � Inheritance increases productivity and quality by reuse. � xtension and re-definition.

Is-A Relationship � A subclass object IS-A super class object � Subclass must have all the behavior of the super class VEHICLE

What is Interface? � An interface is a contract between a class and the outside world. When a class implements an interface, it promises to provide the behavior published by that interface. This section defines a simple interface and explains the necessary changes for any class that implements it. � An Interface defines a set of behaviors without implementation. � Leaves the implementation of those behaviors up to the classes implementing that interface.

Example of Interface

What is Encapsulation? � Encapsulation means to design, produce, and describe software so that it can be easily used without knowing the details of how it works. � Also known as data hiding An analogy: � When you drive a car, you don’t have to know the details of how many cylinders the engine has or how the gasoline and air are mixed and ignited. � Instead you only have to know how to use the controls.

Encapsulation & Information Hiding � A principle of managing complexity. � Encapsulation is the separation of the external property of an object from the internal, implementation details of the object. � Minimize traffic between different parts of the work. � Help minimizing rework when developing a new system. � Localizing volatility : increase reusability. � Prevent a program from becoming interdependent that a small change has massive ripple effects. � Power and attractiveness of encapsulation: abstraction.

Implementing Encapsulation � Separates the user's view of abstraction from details of its implementation. � Implementation of the same abstraction can be substituted freely. � Three different access control. – Private : attributes and operations can be used only by member operations of the class. – Protected : attributes and operations can be used only by member operations and its subclass operations. – Public : attributes and operations can be used by any operations.

What is a Package? � A package is a namespace for organizing classes and interfaces in a logical manner. Placing your code into packages makes large software projects easier to manage. This section explains why this is useful, and introduces you to the Application Programming Interface (API) provided by the Java platform. � The Java platform provides an enormous class library (a set of packages) suitable for use in your own applications. This library is known as the "Application Programming Interface", or "API" for short

Object-Oriented Programming OOP (Object-Oriented Programming) � A design and programming technique � Some terminology: � object - usually a person, place or thing (a noun) � method - an action performed by an object (a verb) � class - a category of similar objects (such as automobiles) � Objects have both data and methods � Objects of the same class have the same data elements and methods � Objects send and receive messages to invoke actions �

Example of an Object Class: automobile Data Items: manufacturer’s name � model name � year made � color � number of doors � size of engine � odometer miles � miles per gallon � Methods: Define data items (specify manufacturer’s name, model, year, etc. ) � Change a data item (color, engine, etc. ) � Display data items � Calculate cost � Calculate mpg �

Why OOP? � Save development time (and cost) by reusing code � once an object class is created it can be used in other applications � Easier debugging � classes can be tested independently � reused objects have already been tested

Object-Oriented Design � Object-oriented design (OOD) is concerned with developing an object-oriented model of a software system to implement the identified requirements. � Many OOD methods have been described since the late 1980 s. The most popular OOD methods include Booch, Buhr, Wasserman, and the HOOD method developed by the European Space Agency [Baudoin 96]. � OOD can yield the following benefits: maintainability through simplified mapping to the problem domain, which provides for less analysis effort, less complexity in system design, and easier verification by the user; reusability of the design artifacts, which saves time and costs; and productivity gains through direct mapping to features of Object-Oriented Programming Languages [Baudoin 96].

Object-Oriented Analysis � OOD builds on the products developed during Object- Oriented Analysis (OOA) by refining candidate objects into classes, defining message protocols for all objects, defining data structures and procedures, and mapping these into an object-oriented programming language (OOPL) (see Object-Oriented Programming Languages). � Several OOD methods (Booch, Shlaer-Mellor, Buhr, Rumbaugh) describe these operations on objects, although none is an accepted industry standard. Analysis and design are closer to each other in the object-oriented approach than in structured analysis and design. For this reason, similar notations are often used during analysis and the early stages of design. However, OOD requires the specification of concepts nonexistent in analysis, such as the types of the attributes of a class, or the logic of its methods.

Object Oriented Software Engineering � � � � Object-oriented software engineering (OOSE) is an object modeling language and methodology OOSE was developed by Ivar Jacobson in 1992 while at Objectory AB. It is the first object-oriented design methodology to employ use cases to drive software design. It also uses other design products similar to those used by OMT. The tool Objectory was created by the team at Objectory AB to implement the OOSE methodology. After success in the marketplace, other tool vendors also supported OOSE. After Rational bought Objectory AB, the OOSE notation, methodology, and tools became superseded. As one of the primary sources of the Unified Modeling Language (UML), concepts and notation from OOSE have been incorporated into UML. The methodology part of OOSE has since evolved into the Rational Unified Process (RUP). The OOSE tools have been replaced by tools supporting UML and RUP. OOSE has been largely replaced by the UML notation and by the RUP methodology.

Object-Oriented Database (OORDBMS) � In an object oriented database, information is represented in the form of objects as used in Object-Oriented Programming. When database capabilities are combined with object programming language capabilities, the result is an object database management system (ODBMS). An ODBMS makes database objects appear as programming language objects in one or more object programming languages. An ODBMS extends the programming language with transparently persistent data, concurrency control, data recovery, associative queries, and other capabilities. � Some object-oriented databases are designed to work well with objectoriented programming languages such as Python, Java, C#, Visual Basic. NET, C++ and Smalltalk. Others have their own programming languages. ODBMSs use exactly the same model as object-oriented programming languages. � Object databases are generally recommended when there is a business need for high performance processing on complex data.

Unified Modeling Language (UML) � The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. � The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.

Goals of UML � Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. � Provide extensibility and specialization mechanisms to extend the core concepts. � Be independent of particular programming languages and development processes. � Provide a formal basis for understanding the modeling language. � Encourage the growth of the OO tools market. � Support higher-level development concepts such as collaborations, frameworks, patterns and components. � Integrate best practices

Conclusion � Object-Oriented Technology � Concepts and Terminology � Object-Oriented Design and Analysis � Object-Oriented Software Engineering � Object-Oriented Programming � Object-Oriented Development � Unified Modeling Language