You are on page 1of 38

OO Concepts and principals

Introduction
‡ We live in a world of objects ‡ Object-Oriented view is an abstraction that models the world in ways that help us to better understand and navigate it ‡ OO approach was first proposed in the late 1960s ‡ As time passes, object technologies are replacing classical software development approaches. Why? ‡ Object technologies lead to reuse, OO software is easier to maintain, to adapt, and to scale.

OO Paradigm
‡ For many years, the term OO was used to denote a software development approach that used one of a number of OO programming languages(e.g. Ada 95, C++, Eiffel, Smalltalk) ‡ Today, the OO paradigm encompasses a complete view of software engineering ‡ Although any one of process models, could be adapted for use with OO, the best choice would be an evolutionary process model

The OO Process Model identify candidate classes Planning Risk Analysis Customer Communication construct nth iteration of system look-up classes in library put new classes in library engineer classes if unavailable extract classes if available Customer Evaluation Engineering. Construction & Release OO analysis OO design OO programming OO testing .

OO Concepts ‡ Classes and class hierarchies ± Instances ± Inheritance ± Abstraction and hiding ‡ Objects ± ± ± ± Attributes Methods Encapsulation Polymorphism ‡ Messages .

Object The object encapsulates both data and the logical procedures required to manipulate the data method #1 data method #2 method #6 method #5 method #4 Achieves ³information hiding´ .

Histogram ) ‡ It decouples objects from one another making each more independent. .g. Line. Pie. ‡ Polymorphism enables a number of different operations to have the same name.Polymorphism ‡ It is a characteristic that greatly reduces the effort required to extend an existing OO system. ‡ For example: drawing different type of graphs( e. ‡ General class graph and one subclass for each type.

return value(s)] message: [receiver.Messages sender object attributes: receiver object attributes: operations: operations: message: [sender. operation. parameters] .

Object Oriented Analysis .

. Entity communications (via messages or events) 1. States and transitions between states 7.Modeling Dimensions Identification/classification of entities. Identification of exclusive services 11. End-to-end processing sequences 10. General-to-specific and whole-to-part entity relationships The modeling 3. Large-scale model partitioning 6. Other entity relationships dimensions 8 and 9 are always present with SA. Detailed specification for functions 8. 4. 2. Description of attributes of entities 5. Top-down decomposition 9.

± Data are considered separately from the processes that transform the data. OO Approaches ‡ Is OO analysis really different from the structured analysis approach? ± A radical change over process oriented (SA).Conventional vs. ± An incremental change over data oriented methodologies (IE). ± System behavior tends to play a secondary role. . ± makes heavy use of functional decomposition. ‡ Structured Analysis (SA): ± takes a distinct input-process-output view of requirements.

‡ Each of them proposed: ± A process for the analysis of the product or system ± A set of diagrams that evolved out of the process. ‡ The most widely use were: ± The Booch method ( an evolutionary approach is maintained).The OOA Landscape ‡ Dozens of OOA method during the late 1980s and into the 1990s are introduced. ± The Rumbaugh method (Object modeling technique (OMT)) ± The Jacobson method (OO Software Engineering (OOSE)) ± The Coad and Yourdon method (One of the easiest) ± The Wirfs-Brock method (do not make clear distinction between design and analysis tasks) . ± A notation that enabled the software engineer to create the analysis model in a consistent manner.

OOA & OOP ‡ OOA is based upon OOP: Classes and members. Objects and attributes and so on ‡ To define them following tasks should be done: ± Basic user requirements should be communicated between customer and software engineer ± Classes must be identified ± Class hierarchy should be specified ± Object to object relationship should be presented ± Object behavior should be modeled ± These task should be reapplied iteratively until model is complete .

Define structures and hierarchies that organize classes. Identify scenarios for use-cases. 7. Review the OO analysis model against usecases or scenarios. Identify attributes and operations for each system object.Generic Steps for OOA 1. Elicit customer requirements for the system. 2. 3. Select classes and objects using basic requirements as a guide. . 4. Build an object-behavior model. 6. 5.

James Rumbaugh and Ivar Jacobson combine the best features into a unified method called: Unified Modeling Language (UML) ‡ UML allows a software engineer to express and analysis model using a modeling notation that is governed by a set of Syntactic. (Word in natural language) ± The semantics tells us what each symbols means and how it should be interpreted. and Pragmatic rules. Semantic. (Meaning of words in natural language) ± The pragmatic rules define the intentions of the symbols through which the perpose of the model is achieved and become understandable. ± The syntax tells us how the symbols should look and how they are combined. (The rules for constructing sentences that are clear and understandable in natural language) .A Unified Approach to OOA ‡ Grady Booch.

That is.UML and Analysis Views ‡ User model view. The structural and behavioral aspects of the environment in which the system is to be implemented are represented. . This part of the analysis model represents the dynamic or behavioral aspects of the system. ‡ Implementation model view. objects. ‡ Behavioral model view. ‡ Environment model view. static structure (classes. ‡ UML design modeling addresses the other three views. This view represents the system (product) from the user¶s (called ³actors´ in UML) perspective. ‡ Structural model view. Data and functionality is viewed from inside the system. The structural and behavioral aspects of the system are represented as they are to be built. and relationships) is modeled. ‡ UML analysis modeling focuses on the first two views of the system.

cheaper and more reliable. ‡ But where did such a library come from? By applying domain analysis. ‡ Using a robust class library produces the system faster. ‡ Domain Analysis is performed to create a library of reusable classes applicable to an entire category of applications. .Domain Analysis ‡ OO Analysis can occur at many different levels of abstraction: ± At the business or enterprise level ± At the business area level ± At an application level ‡ OOA at the middle level called Domain Analysis.

It can be viewed as an umbrella activity for the software process.Domain Analysis Process ‡ ‡ ‡ ‡ The goal: to find or create those classes that are broadly applicable. so that they may be reused. The role of domain analyst is to design and build reusable components that maybe used by many people working on similar but not necessarily the same applications. Key inputs and outputs for the domain analysis process: class taxonomies SOURCES OF DOMAIN KNOWLEDGE technical literature existing applications customer surveys expert advice current/future requirements DOMAIN ANALYSIS reuse standards functional models domain languages DOMAIN ANALYSIS MODEL .

Domain Analysis Activities (1) ‡ Define the domain to be investigated. parts of existing non-OO applications. Define naming conventions for each item. . metrics and COTS non-OO software. standards and guidelines. ± ± ± ± ± Organize items into categories. procedures. Establish classification hierarchy when appropriate. product category ± Extract both OO and non-OO items. ‡ OO-items such as: application and support (GUI. Commercial off-the-shelf (COTS) component libraries and test cases. system type. plans. DB) classes. Define the general defining characteristics of the categories. ‡ Non-OO items such as: policies. ‡ Categorize the items extracted from the domain. ± Isolate the business area. Propose a classification scheme for the categories.

‡ Analyze each application in the sample. ± ± ± ± Identify candidate reusable objects. Indicate the reasons that the object has been identified for reuse. Define adaptions to the object that may also be reusable. .Domain Analysis Activities (2) ‡ Collect a representative sample of applications in the domain. ± As a basis for design and construction of domain objects. ± Ensure that the application has items that fit into categories. ± Identify the object by name and use configuration management techniques to control them (chapter 9). Estimate the percentage of applications in the domain that make reuse of the object. ‡ Develop an analysis model for the objects.

A Generic View ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ define use cases extract candidate classes establish basic class relationships define a class hierarchy identify attributes for each class specify methods that service the attributes indicate how classes/objects are related build a behavioral model iterate on the first five steps .OOA.

± Programs. if the system is human-interactive. if the system is involved in process control. ± Machines. ‡ A series of techniques may be used to gather basic customer requirements. the modeling of the software begins. if the system coordinates and controls applications ‡ Once the scenario of usage has been defined. .The OOA Process ‡ The OOA process begins with an understanding of the manner in which the system will be used by: ± People.

Use Cases .

Object Oriented Design .

‡ OOD results in a design that achieves a number of different levels of modularity.OOD ‡ OOD transforms the analysis model created using OOA into a design model that serves as a blueprint for software construction. ‡ Subsystems: Major system components. ‡ Objects: Data and the operations. ‡ Four important software design concepts: ± ± ± ± Abstraction Information Hiding Functional Independence Modularity .

OOD ‡ The subsystem layer: Representation of each of the subsystems that enable the software to achieve its customer defined requirements. ‡ ‡ res p o n s ib ilities d es ig n m es s ag e d es ig n c las s a n d o b jec t d es ig n s u b s y s t em d e s ig n ‡ . (generalization) and representation of objects. The message layer: The design details of communication of each object with its collaborators. (external and internal interfaces) The responsibilities layer: Data Structure and algorithmic design for all attributes and operations. The class and object layer: The class hierarchies.

c o llab o rato r s CRC In d ex C ar ds O bjec t relat io n s h ip m o d el res p o n s ib il ities d es ig n U s e c as es m es s ag e d es i g n C l as s an d o b je c t d es i g n s u b s y s t em d es i g n O b jec t -B eh av io r M odel THE ANALYSIS MODEL THE DESIGN MODEL .OOA to OOD A t tr ib u t es . o p erat i o n s .

OOA to OOD n aly s is M o d el c l as s es at tr ib u t es et h o d s r ela t io n s h iip s p b e h a v io r D e s iig n M o d el g o b jec t s d ata s tr u c t u r es alg o r it h s es s ag in g in c o n tr o l .

‡ composability²the degree to which a design method ensures that program components (modules). . ‡ continuity²the ability to make small changes in a program and have these changes manifest themselves with corresponding changes in just one or a very few modules.Design Issues ‡ decomposability²the facility with which a design method helps the designer to decompose a large problem into subproblems that are easier to solve. once designed and built. ‡ understandability²the ease with which a program component can be understood without reference to other information or other modules. can be reused to create other systems. ‡ protection²a architectural characteristic that will reduce the propagation of side affects if an error does occur in a given module.

‡ Human interaction component ²the subsystems that implement the user interface (this included reusable GUI subsystems). ‡ Data management component²the subsystem that is responsible for the storage and retrieval of objects. . ‡ Task Management Component²the subsystems that are responsible for controlling and coordinating concurrent tasks that may be packaged within a subsystem or among different subsystems.Generic Components for OOD ‡ Problem domain component²the subsystems that are responsible for implementing customer requirements directly.

Process Flow for OOD .

Develop a design for the user interface.System Design Process ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ Partition the analysis model into subsystems. Choose a basic strategy for implementing data management. Review and consider trade-offs. including task management. Identify concurrency that is dictated by the problem. Consider how boundary conditions should be handled. Identify global resources and the control mechanisms required to access them. Design an appropriate control mechanism for the system. trade- . Allocate subsystems to processors and tasks.

System Design client subsyste request server subsyste contract request peer subsyste request contract contract peer subsyste .

Subsystem Example Control panel subsystem Sensor subsystem request for status assign to zone test status request for system status specification of type of alarm periodic status check request for alarm notification periodic check-in require for configuration update Central communication subsystem .

´ the classes within a subsystem should collaborate only with other classes within the subsystem.Subsystem Design Criteria ‡ The subsystem should have a well-defined interface through which all communication with the rest of the system occurs. . ‡ A subsystem can be partitioned internally to help reduce complexity. ‡ The number of subsystems should be kept small. ‡ With the exception of a small number of ³communication classes.

Subsystem Collaboration Table .

Object Design ‡ A protocol description establishes the interface of an object by defining each message that the object can receive and the related operation that the object performs ‡ An implementation description shows implementation details for each operation implied by a message that is passed to an object. ± information about the object's private part ± internal details about the data structures that describe the object¶s attributes ± procedural details that describe operations .

Design Patterns ‡ add some example .