Object Oriented Design
Content
Object Oriented Design
Shruti Jathar
Chapter -1
Introduction
± Two views of software Developments: SSAD and OOAD. ± Why Object ± Orientation?
Structured Programming
Also called modular programming is a subset of procedural programming. Enforces a logical structure on the program. More efficient and easier to understand and modify. Importance is given to the procedures that manipulate the data. Follows top-down approach. Easy to understand and follows simple hierarchy. Basic three structures used are : decisions, sequences, and loops. Eg. Pascal, and dBASE, Ada.
Object Oriented Programming
Organized around "objects" rather than data and Logic. Importance is given to the objects rather than procedures. Anything a program wants to deal with is treated as an object. Objects range from human beings (described by name, address etc) to buildings and floors (whose properties can be described ) down to the little widgets on your computer desktop. Objects have their own properties and functionality ( methods ). Concepts in Object Oriented Programming ± Class ± Objects ± Encapsulation / Data Hiding ± Polymorphism ( many Forms ± Functions / Operators ) ± Inheritance ( Reduce Redundancy )
What is System Analysis and Design?
Definition : Systems analysis is the interdisciplinary part of science, dealing with analysis of sets of interacting entities and systems, often prior to their automation as computer systems, and the interactions within those systems. System Analysis is "an explicit formal inquiry carried out to help someone, referred to as the decision maker, identify a better course of action and make a better decision than he might have otherwise made."
Structured System Analysis & Design
Evolved from Structured programming. SSAD is process oriented. Processes are of primary focus. System is broken down using DFD. Components of the system are derived from the DFD's. There are definable steps: planning, analysis, design, and implementation from start to finish for the systems development life cycle. In SSAD there is a separation of the data and processes.
Object Oriented Analysis & Design
Evolved from Object-Oriented Prg. OOAD is data oriented; data is of primary focus. System is broken down using Use Cases. Components of system are derived from the class diagrams and (UML). Here there is an iterative approach involving continuous testing and refinement of the system from start. In OOAD there is encapsulation of the data and processes into objects.
Graphical design tools are used to analyze and model the systemrequirements. For each methodology there is a step by step process for developing the system. Both techniques emphasize the documentation of the system and its requirements.
Advantages Of SSAD
SSAD makes tracking bugs easier for project management. It is visual and makes understanding easier for the users/programmers. Makes good use of it graphical analysis and tools such as DFD's. Very well known and established methodology in the industry. Consequently a mature technique. Finally SSAD is relatively simple and easy to understand.
Limitations Of SSAD
Since process-oriented, it ignores the non-functional requirements. There is less direct management involvement in SSAD. Requirement change means restarting the entire process. There is some but not enough user/analyst interaction. Except for the logical design and the DFD's, SSAD provides no other tools for communication with users, and therefore it is more difficult for users to measure progress. It is difficult to decide when to stop functional decomposition and to start building the system. Does not always address the user's requirements. SSAD is not a good fit for object-oriented programming languages.
What is Object-Oriented Design ?
Process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object Oriented Design refers to the objects that make up a business. An object-oriented system studies the interaction of various objects used by a system to solve the problem.
Object Oriented Concepts
Object / Class : An association of data with the methods or functions that act on the data. This is called a class, or object (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do. An object can be part of a class, which is a set of objects that are similar. Information Hiding : The ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class. Inheritance: The ability for a class to extend or override functionality of another class. The so-called subclass has a whole section that is the superclass and then it has its own set of functions and data.
Interface : The ability to defer the implementation of a method. The ability to define the functions or methods signatures without implementing them. Polymorphism : The ability to replace an object with its subobjects. The ability of an object-variable to contain, not only that object, but also all of its subobjects.
Object-Oriented Design Concepts
Input (sources) 1.Use Case : A description of sequences of events that, lead to a system doing something useful. Each use case provides one or more scenarios that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into use case diagrams. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform. 2.System Sequence Diagram : System Sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.
3.User Input : Document that shows and describes the look and feel of the end product's user interface. Helps to visualize the end-product and therefore helps the designer. 4.Relational Data Model : (if applicable): A data model is an abstract model that describes how data is represented and used. If an object database is not used, the relational data model should usually be created before the design, since the strategy chosen for objectrelational mapping is an output of the OO design process. However, it is possible to develop the relational data model and the objectoriented design artefacts in parallel, and the growth of an artefact can stimulate the refinement of other artefacts.
Output (deliverables) of object-oriented design Sequence Diagrams: Extend the System Sequence Diagram to add specific objects that handle the system events. A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. Class Diagram: A class diagram is a type of static structure UML diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. The messages and classes identified through the development of the sequence diagrams can serve as input to the automatic generation of the global class diagram of the system.
--- END ---
Chapter -2
The Object Paradigm - Object and classes - Abstraction and encapsulation - Methods and Message - Interfaces, Inheritance and Polymorphism - Access Control - The Business case for OO Developments
Objects
Objects are the entities of which the world is comprised. Objects interact with each other in real world. Object can be considered as anything a problem has to deal with. Objects can be as simple as a pen , pencil, person or complex like a bank account. Objects have unique features ( attributes ) and functionality. Object is characterized by its behavior. Any meaningful object has its own attributes and functionality.
Classes
Objects differ from each other only in the value they hold. Eg. Blue Crayon --- holds value ³blue´ Red Crayon --- holds value ³red´ Thus Crayon is a generalized Class and bluecrayon and redcrayon will be objects Crayon class. A class is an abstract description of a set of objects. A class contain the descriptions of all the behaviors of the objects that it represents. A class is a template for the creation of a particular type of object. Class can be summarized as a collection of both data (properties/attributes) and executable code (methods/functions).
Abstraction
In order to process something from the real world we have to extract the essential characteristics of that object. Data abstraction can be viewed as the process of refining away the unimportant details of an object, so that only the useful characteristics that define it remain.
Encapsulation
Encapsulation is one step beyond abstraction Encapsulation links (binds) the data to the operations that can be performed upon the data. Encapsulation enforces integrity (i.e. to make sure data is used in an appropriate manner) by preventing unauthenticated programmers from accessing data. Thus encapsulation, provides data security. Encapsulation is defined as the process of wrapping up the data members and member functions together into a single unit.
struct Stud { private: int no ; char name[10]; public : void fun1() { //code ; } void fun2() { // code ; } }
Polymorphism
Polymorphism refers to the ability of executing different operations in response to the same message. Polymorphism can also be static or dynamic. The mechanism used to link the message with the method in dynamic polymorphism is known as late or dynamic binding Linking done on compile time it is known as early/static binding. Polymorphism is implemented using four different mechanisms: -Overloading: One Operator / Function ( method) name when used to perform multiple tasks is called Overloading.It uses early binding. -Overriding: When a derived class re-defines a method inherited from the base class it may use late binding and is termed as overriding.
Interface
Objects interact with the outside world through the methods. Methods form the object's interface with the outside world; eg. Buttons of your TV, are the interface between you and the electrical wiring. An interface is a group of related methods with empty bodies. The area of any shape can be calculated easily if an interface ³Shape´ is specified as follows: Eg .interface Shape { int calArea(); } NOTE : This interface could be used as per your Shape-Rect,Circle,triangle class Rect implements Shape int calArea() { { // Actual code of the method } // remainder of this class implemented as before }
Inheritance
This feature is used to reduce redundancy in the program. Inheritance allows you to write common code. A new class can be created which inherits all of the functionality and data of some other class. The new class can choose to respond to any given message in a different way than the class it inherits from does and can also define new methods. The new class can modify the data used to implement the class it inherits from and can add to that data.
Terminology These data types are called classes. A variable of a given class is an instance of that class. Object refers to an instance of a class. The operations that a class implements are called methods (not functions). Instead of calling a function to perform some operation on an object, we send that object a message asking it to perform that operation on itself. A given message may be meaningful to different classes of objects. (e.g. "size" is meaningful both to a stack and a queue even though each may calculate its size in a very different way).
Terminology A class which inherits from another class is a subclass of the class it inherits from. A class is a subclass of its superclass. When a subclass responds to a message in a different way that its superclass does, the subclass is said to have overridden its superclass's method. Subclass is often used as a verb: "I subclassed the Vehicle class to create the Car class."
OOD - Terminology Object-oriented programmers use phrases like: "When the user presses this button, it sends a message to this object which calculates something and then sends a message to this other object which updates this and..." instead of: "We wait for the user to press a button and then decide which one it was, and based on that, we decide what to do, then we wait for the user to do something else..."
Chapter ± 3
Object Oriented Methodologies Diagramming and Notations used in UML Generalisation Aggregation Association
OOD method of Grady Booch Also known as OOAD, is a originator to the Unified Modeling (UML). Includes six types of diagrams: class, object, state transition, interaction, module, and process. Widely used and covers analysis & design phases of object oriented system. Booch's notation is regarded as the most complete for representing objectoriented systems. Booch methodology considers macro and micro development processes. Here one starts with class and object diagrams in the analysis phase and refine these diagrams through various steps (within the same diagram, undergoing a refinement process as long as the problem domain gets more and more understood), following an evolutionary approach. Design symbols are to be added when ready to generate code, usually representing very final implementation decisions.
-Macro Development Process
-Technical management of the system.
-Consider goals and develop a prototype.
-Use of class and Object diagrams to analyze and design the system. -Architecture of system is studied using interaction of classes and objects. -Refining the system after carrying out many iterations and producing a stream of software implementation. -5.Maintainence : Finally once the system is ready, localised changes are needed to be made and bugs need to be removed in this stage.
Micro Development Process : Each macro process has its own micro development process containing following steps 1.Identify classes and objects. 2.Identify class and object semantics. 3.Identify class and object relationships. 4.Identify class and Object interfaces and implementations.
OOD method - Rambaugh
Presents Object Modeling Technique which are useful for analysis, design, and implementation of the system. This is the first approach to identify and model objects making a system. Models specifies detailed interaction and state changes of objects in a system Four phases in this OMT are ² Analysis ² System Design ² Object Design ² Implementation.
1.State chart diagram: UML State charts describe state of the object when object reacts to different . They are needed when an object has a different reaction dependent on its state. The state design pattern uses polymorphism to define behaviour. Eg.
2.Class diagram: Class is representation of an object. It is a template from which objects are created. Class is the main building block of object-oriented application. Classes are typically shown as rectangles with three sections: the top section for the name of the class, the middle section for the attributes of the class, and the bottom section for the methods of the class. Eg, Course class can be described as ..
3.Use Case diagram A use case in SE is description of a system·s behaviour. Use case describes "who" can do "what" with the system. These describe the interaction between one or more actors and the system itself, in a sequence of simple steps. Actors are one which exists outside the system under study. Actors take part in the activities system to achieve some goal. Actors may be end users, other systems, or hardware devices. Each use case is a complete series of events, described from the point of view of the actor. The two main components of a use case diagram are use cases and actors.
Sales Order System
4.Activity diagram: They are graphical representations of workflows of stepwise activities and actions. In the Unified Modeling Language, activity diagrams can be used to describe the step-by-step workflows of the components in a system. An activity diagram shows the overall flow of control. Activity diagram is a simple and intuitive illustration of what happens in a workflow, what activities can be done in parallel, and whether there are alternative paths through the workflow. These diagrams are informative and take support for choice, iteration and concurrency.
5.Sequence diagram: These represent sequential nature of the logic. Boxes across the top represent objects, classes, or actors. Objects have labels in the standard UML format name: ClassName. The dashed lines hanging from the boxes are called object lifelines, representing the life span of the object during the scenario being modelled. The long, thin boxes on the lifelines are activation boxes, also called method-invocation boxes, which indicate processing is being performed by the target object/class to fulfill a message.
Main Purpose The main purpose of a sequence diagram is to define event sequences. The focus is less on messages themselves and more on the order in which messages occur. Most sequence diagrams will communicate what messages are sent between a system's objects as well as the order in which they occur. The diagram conveys this information along the horizontal and vertical dimensions: the vertical dimension shows, top down, the time sequence of messages/calls as they occur, and the horizontal dimension shows, left to right, the object instances that the messages are sent to.
Generalisation
Generalization relationship is a relationship in which one element (the child) is based on another element (the parent). Classes are composed of three things: a name, attributes, and operations.
Association This is the most common relationship in a class diagram. This shows the relationship between instances of classes. Eg. Class Order is associated with class Customer. The multiplicity of the association denotes the number of objects that can participate in then relationship.For example, an Order object can be associated to only one customer, but a customer can be associated to many orders.
Chapter ± 4 Object-Oriented Systems Development Process Rational Unified Process Four Major phases:Inception, Elaboration, Construction, Transition Requirements Engineering Problem analysis. Understanding Stockholders need Type of requirements. Use-case Model: Writing Requirements
Rational Unified Process
It is a Software Engineering Process which provides disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software. The development team for the Rational Unified Process are working to ensure that the process is continuously updated and improved The Rational Unified Process is supported by tools, which automate large parts of the process. Rational Unified Process divides one development cycle in four consecutive phases.
Rational Unified Process phases. Inception phase Elaboration phase Construction phase Transition phase Note : Each phase is concluded with a milestone - A point where critical decisions must be made. - Each phase has a specific purpose.
1.Inception Phase During inception establish the business case for the system and delimit the project scope. -Identify all external entities with which system will interact (actors) -Define the nature of the interaction at a high-level. -This involves identifying all use cases and describing a few significant ones. -The business case includes success criteria, risk assessment, and estimate of the resources needed, and a phase plan showing dates of major milestones.
The outcome of the inception phase is: Vision document : General vision of the core project's requirements, key features, and main constraints. A initial use-case model (10% -20%) complete) An initial project glossary (may optionally be partially expressed as a domain model). An initial business case, which includes business context, success criteria (revenue projection, market recognition, and so on), and financial forecast. An initial risk assessment. A project plan, showing phases and iterations. A business model, if necessary. One or several prototypes.
The evaluation criteria for the inception phase are: Stakeholder concurrence on scope definition and cost/schedule estimates. Requirements understanding as evidenced by the primary use cases. Credibility of the cost/schedule estimates, priorities, risks, and development process. Depth and breadth of any architectural prototype that was developed. Actual expenditures versus planned expenditures. The project may be cancelled or considerably re-thought if it fails to pass this milestone.
2.Elaboration Phase
Purpose is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the project. To accomplish these objectives, you must have the ³mile wide and inch deep´ view of the system. Architectural decisions have to be made with an understanding of the whole system: scope and major requirements. Elaboration phase is the most critical of the four phases. Here the hard ³engineering´ is considered complete and the project undergoes most important decision : whether or not to commit the project.
The elaboration phase activities ensure that the architecture, requirements and plans are stable enough, and the risks are sufficiently reduced. This predictably determines the cost and schedule for the completion of the development. Executable architecture prototype is built in one or more iterations, depending on the scope, size, risk, and novelty of the project.
The outcome of the elaboration phase is: A use-case model (at least 80% complete) ² all use cases and actors have been identified, and most usecase descriptions have been developed. Supplementary requirements capturing the non functional requirements and any requirements that are not associated with a specific use case. Software Architecture Description. An executable architectural prototype. A revised risk list and a revised business case. A development plan for the overall project, including the coarsegrained project plan, showing iterations´ and evaluation criteria for each iteration. An updated development case specifying the process to be used. A preliminary user manual (optional).
MileStone -The second important project milestone, the Lifecycle Architecture Milestone. -Here Examine the detailed system objectives and scope, the choice of architecture, and the resolution of the major risks.
3.Construction Phase
Here all features are thoroughly tested. Construction phase is, in one sense, a manufacturing process.. Managing resources and controlling operations to optimize costs, schedules, and quality. In other words, one of the critical qualities of the architecture is its ease of construction. The software product integrated on the adequate platforms. The outcome of the construction phase is a product ready to put in hands of its end users. It consists of: The user manuals. A description of the current release. Milestone : Initial Operational Capability Here you decide if the software, the sites, and the users are ready to go operational, without exposing the project to high risks
The evaluation criteria for the construction phase involve answering these questions: Is this product release stable and mature enough to be deployed ? Are all stakeholders ready for the transition into the user community? Are the actual resource expenditures versus planned expenditures still acceptable? Transition may have to be postponed by one release if the project fails to reach this milestone
4.Transition Phase
The transition phase focuses on the activities required to place the software into the hands of the users. Typically, this phase includes several iterations, including beta releases, general availability releases, as well as bug-fix and enhancement releases. Considerable effort is expended in developing user-oriented documentation, training users, supporting users in their initial product use, and reacting to user feedback. At this point in the lifecycle, however, user feedback should be confined primarily to product tuning, configuring, installation, and usability issues. The primary objectives of the transition phase include: Achieving user self-supportability Achieving stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision Achieving final product baseline as rapidly and cost effectively as practical This phase can range from being very simple to extremely complex, depending on the type of product.
At the end of the transition phase is the fourth important project milestone, the Product Release Milestone. At this point, you decide if the objectives were met, and if you should start another development cycle. In some cases, this milestone may coincide with the end of the inception phase for the next cycle. The primary evaluation criteria for the transition phase involve the answers to these questions: Is the user satisfied? Are the actual resources expenditures versus planned expenditures still acceptable?
Iterations Each phase in the Rational Unified Process can be further broken down into iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system. Compared to the traditional waterfall process, the iterative process has the following advantages: Risks are mitigated earlier Change is more manageable Higher level of reuse The project team can learn along the way Better overall quality Static Structure of the Process A process describes who is doing what, how, and when. The Rational Unified Process is represented using four primary modeling elements: Workers, the µwho¶ Activities, the µhow¶ Artifacts, the µwhat¶ Workflows, the µwhen¶
Shruti Jathar
Chapter -1
Introduction
± Two views of software Developments: SSAD and OOAD. ± Why Object ± Orientation?
Structured Programming
Also called modular programming is a subset of procedural programming. Enforces a logical structure on the program. More efficient and easier to understand and modify. Importance is given to the procedures that manipulate the data. Follows top-down approach. Easy to understand and follows simple hierarchy. Basic three structures used are : decisions, sequences, and loops. Eg. Pascal, and dBASE, Ada.
Object Oriented Programming
Organized around "objects" rather than data and Logic. Importance is given to the objects rather than procedures. Anything a program wants to deal with is treated as an object. Objects range from human beings (described by name, address etc) to buildings and floors (whose properties can be described ) down to the little widgets on your computer desktop. Objects have their own properties and functionality ( methods ). Concepts in Object Oriented Programming ± Class ± Objects ± Encapsulation / Data Hiding ± Polymorphism ( many Forms ± Functions / Operators ) ± Inheritance ( Reduce Redundancy )
What is System Analysis and Design?
Definition : Systems analysis is the interdisciplinary part of science, dealing with analysis of sets of interacting entities and systems, often prior to their automation as computer systems, and the interactions within those systems. System Analysis is "an explicit formal inquiry carried out to help someone, referred to as the decision maker, identify a better course of action and make a better decision than he might have otherwise made."
Structured System Analysis & Design
Evolved from Structured programming. SSAD is process oriented. Processes are of primary focus. System is broken down using DFD. Components of the system are derived from the DFD's. There are definable steps: planning, analysis, design, and implementation from start to finish for the systems development life cycle. In SSAD there is a separation of the data and processes.
Object Oriented Analysis & Design
Evolved from Object-Oriented Prg. OOAD is data oriented; data is of primary focus. System is broken down using Use Cases. Components of system are derived from the class diagrams and (UML). Here there is an iterative approach involving continuous testing and refinement of the system from start. In OOAD there is encapsulation of the data and processes into objects.
Graphical design tools are used to analyze and model the systemrequirements. For each methodology there is a step by step process for developing the system. Both techniques emphasize the documentation of the system and its requirements.
Advantages Of SSAD
SSAD makes tracking bugs easier for project management. It is visual and makes understanding easier for the users/programmers. Makes good use of it graphical analysis and tools such as DFD's. Very well known and established methodology in the industry. Consequently a mature technique. Finally SSAD is relatively simple and easy to understand.
Limitations Of SSAD
Since process-oriented, it ignores the non-functional requirements. There is less direct management involvement in SSAD. Requirement change means restarting the entire process. There is some but not enough user/analyst interaction. Except for the logical design and the DFD's, SSAD provides no other tools for communication with users, and therefore it is more difficult for users to measure progress. It is difficult to decide when to stop functional decomposition and to start building the system. Does not always address the user's requirements. SSAD is not a good fit for object-oriented programming languages.
What is Object-Oriented Design ?
Process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object Oriented Design refers to the objects that make up a business. An object-oriented system studies the interaction of various objects used by a system to solve the problem.
Object Oriented Concepts
Object / Class : An association of data with the methods or functions that act on the data. This is called a class, or object (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do. An object can be part of a class, which is a set of objects that are similar. Information Hiding : The ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class. Inheritance: The ability for a class to extend or override functionality of another class. The so-called subclass has a whole section that is the superclass and then it has its own set of functions and data.
Interface : The ability to defer the implementation of a method. The ability to define the functions or methods signatures without implementing them. Polymorphism : The ability to replace an object with its subobjects. The ability of an object-variable to contain, not only that object, but also all of its subobjects.
Object-Oriented Design Concepts
Input (sources) 1.Use Case : A description of sequences of events that, lead to a system doing something useful. Each use case provides one or more scenarios that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into use case diagrams. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform. 2.System Sequence Diagram : System Sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.
3.User Input : Document that shows and describes the look and feel of the end product's user interface. Helps to visualize the end-product and therefore helps the designer. 4.Relational Data Model : (if applicable): A data model is an abstract model that describes how data is represented and used. If an object database is not used, the relational data model should usually be created before the design, since the strategy chosen for objectrelational mapping is an output of the OO design process. However, it is possible to develop the relational data model and the objectoriented design artefacts in parallel, and the growth of an artefact can stimulate the refinement of other artefacts.
Output (deliverables) of object-oriented design Sequence Diagrams: Extend the System Sequence Diagram to add specific objects that handle the system events. A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. Class Diagram: A class diagram is a type of static structure UML diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. The messages and classes identified through the development of the sequence diagrams can serve as input to the automatic generation of the global class diagram of the system.
--- END ---
Chapter -2
The Object Paradigm - Object and classes - Abstraction and encapsulation - Methods and Message - Interfaces, Inheritance and Polymorphism - Access Control - The Business case for OO Developments
Objects
Objects are the entities of which the world is comprised. Objects interact with each other in real world. Object can be considered as anything a problem has to deal with. Objects can be as simple as a pen , pencil, person or complex like a bank account. Objects have unique features ( attributes ) and functionality. Object is characterized by its behavior. Any meaningful object has its own attributes and functionality.
Classes
Objects differ from each other only in the value they hold. Eg. Blue Crayon --- holds value ³blue´ Red Crayon --- holds value ³red´ Thus Crayon is a generalized Class and bluecrayon and redcrayon will be objects Crayon class. A class is an abstract description of a set of objects. A class contain the descriptions of all the behaviors of the objects that it represents. A class is a template for the creation of a particular type of object. Class can be summarized as a collection of both data (properties/attributes) and executable code (methods/functions).
Abstraction
In order to process something from the real world we have to extract the essential characteristics of that object. Data abstraction can be viewed as the process of refining away the unimportant details of an object, so that only the useful characteristics that define it remain.
Encapsulation
Encapsulation is one step beyond abstraction Encapsulation links (binds) the data to the operations that can be performed upon the data. Encapsulation enforces integrity (i.e. to make sure data is used in an appropriate manner) by preventing unauthenticated programmers from accessing data. Thus encapsulation, provides data security. Encapsulation is defined as the process of wrapping up the data members and member functions together into a single unit.
struct Stud { private: int no ; char name[10]; public : void fun1() { //code ; } void fun2() { // code ; } }
Polymorphism
Polymorphism refers to the ability of executing different operations in response to the same message. Polymorphism can also be static or dynamic. The mechanism used to link the message with the method in dynamic polymorphism is known as late or dynamic binding Linking done on compile time it is known as early/static binding. Polymorphism is implemented using four different mechanisms: -Overloading: One Operator / Function ( method) name when used to perform multiple tasks is called Overloading.It uses early binding. -Overriding: When a derived class re-defines a method inherited from the base class it may use late binding and is termed as overriding.
Interface
Objects interact with the outside world through the methods. Methods form the object's interface with the outside world; eg. Buttons of your TV, are the interface between you and the electrical wiring. An interface is a group of related methods with empty bodies. The area of any shape can be calculated easily if an interface ³Shape´ is specified as follows: Eg .interface Shape { int calArea(); } NOTE : This interface could be used as per your Shape-Rect,Circle,triangle class Rect implements Shape int calArea() { { // Actual code of the method } // remainder of this class implemented as before }
Inheritance
This feature is used to reduce redundancy in the program. Inheritance allows you to write common code. A new class can be created which inherits all of the functionality and data of some other class. The new class can choose to respond to any given message in a different way than the class it inherits from does and can also define new methods. The new class can modify the data used to implement the class it inherits from and can add to that data.
Terminology These data types are called classes. A variable of a given class is an instance of that class. Object refers to an instance of a class. The operations that a class implements are called methods (not functions). Instead of calling a function to perform some operation on an object, we send that object a message asking it to perform that operation on itself. A given message may be meaningful to different classes of objects. (e.g. "size" is meaningful both to a stack and a queue even though each may calculate its size in a very different way).
Terminology A class which inherits from another class is a subclass of the class it inherits from. A class is a subclass of its superclass. When a subclass responds to a message in a different way that its superclass does, the subclass is said to have overridden its superclass's method. Subclass is often used as a verb: "I subclassed the Vehicle class to create the Car class."
OOD - Terminology Object-oriented programmers use phrases like: "When the user presses this button, it sends a message to this object which calculates something and then sends a message to this other object which updates this and..." instead of: "We wait for the user to press a button and then decide which one it was, and based on that, we decide what to do, then we wait for the user to do something else..."
Chapter ± 3
Object Oriented Methodologies Diagramming and Notations used in UML Generalisation Aggregation Association
OOD method of Grady Booch Also known as OOAD, is a originator to the Unified Modeling (UML). Includes six types of diagrams: class, object, state transition, interaction, module, and process. Widely used and covers analysis & design phases of object oriented system. Booch's notation is regarded as the most complete for representing objectoriented systems. Booch methodology considers macro and micro development processes. Here one starts with class and object diagrams in the analysis phase and refine these diagrams through various steps (within the same diagram, undergoing a refinement process as long as the problem domain gets more and more understood), following an evolutionary approach. Design symbols are to be added when ready to generate code, usually representing very final implementation decisions.
-Macro Development Process
-Technical management of the system.
-Consider goals and develop a prototype.
-Use of class and Object diagrams to analyze and design the system. -Architecture of system is studied using interaction of classes and objects. -Refining the system after carrying out many iterations and producing a stream of software implementation. -5.Maintainence : Finally once the system is ready, localised changes are needed to be made and bugs need to be removed in this stage.
Micro Development Process : Each macro process has its own micro development process containing following steps 1.Identify classes and objects. 2.Identify class and object semantics. 3.Identify class and object relationships. 4.Identify class and Object interfaces and implementations.
OOD method - Rambaugh
Presents Object Modeling Technique which are useful for analysis, design, and implementation of the system. This is the first approach to identify and model objects making a system. Models specifies detailed interaction and state changes of objects in a system Four phases in this OMT are ² Analysis ² System Design ² Object Design ² Implementation.
1.State chart diagram: UML State charts describe state of the object when object reacts to different . They are needed when an object has a different reaction dependent on its state. The state design pattern uses polymorphism to define behaviour. Eg.
2.Class diagram: Class is representation of an object. It is a template from which objects are created. Class is the main building block of object-oriented application. Classes are typically shown as rectangles with three sections: the top section for the name of the class, the middle section for the attributes of the class, and the bottom section for the methods of the class. Eg, Course class can be described as ..
3.Use Case diagram A use case in SE is description of a system·s behaviour. Use case describes "who" can do "what" with the system. These describe the interaction between one or more actors and the system itself, in a sequence of simple steps. Actors are one which exists outside the system under study. Actors take part in the activities system to achieve some goal. Actors may be end users, other systems, or hardware devices. Each use case is a complete series of events, described from the point of view of the actor. The two main components of a use case diagram are use cases and actors.
Sales Order System
4.Activity diagram: They are graphical representations of workflows of stepwise activities and actions. In the Unified Modeling Language, activity diagrams can be used to describe the step-by-step workflows of the components in a system. An activity diagram shows the overall flow of control. Activity diagram is a simple and intuitive illustration of what happens in a workflow, what activities can be done in parallel, and whether there are alternative paths through the workflow. These diagrams are informative and take support for choice, iteration and concurrency.
5.Sequence diagram: These represent sequential nature of the logic. Boxes across the top represent objects, classes, or actors. Objects have labels in the standard UML format name: ClassName. The dashed lines hanging from the boxes are called object lifelines, representing the life span of the object during the scenario being modelled. The long, thin boxes on the lifelines are activation boxes, also called method-invocation boxes, which indicate processing is being performed by the target object/class to fulfill a message.
Main Purpose The main purpose of a sequence diagram is to define event sequences. The focus is less on messages themselves and more on the order in which messages occur. Most sequence diagrams will communicate what messages are sent between a system's objects as well as the order in which they occur. The diagram conveys this information along the horizontal and vertical dimensions: the vertical dimension shows, top down, the time sequence of messages/calls as they occur, and the horizontal dimension shows, left to right, the object instances that the messages are sent to.
Generalisation
Generalization relationship is a relationship in which one element (the child) is based on another element (the parent). Classes are composed of three things: a name, attributes, and operations.
Association This is the most common relationship in a class diagram. This shows the relationship between instances of classes. Eg. Class Order is associated with class Customer. The multiplicity of the association denotes the number of objects that can participate in then relationship.For example, an Order object can be associated to only one customer, but a customer can be associated to many orders.
Chapter ± 4 Object-Oriented Systems Development Process Rational Unified Process Four Major phases:Inception, Elaboration, Construction, Transition Requirements Engineering Problem analysis. Understanding Stockholders need Type of requirements. Use-case Model: Writing Requirements
Rational Unified Process
It is a Software Engineering Process which provides disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software. The development team for the Rational Unified Process are working to ensure that the process is continuously updated and improved The Rational Unified Process is supported by tools, which automate large parts of the process. Rational Unified Process divides one development cycle in four consecutive phases.
Rational Unified Process phases. Inception phase Elaboration phase Construction phase Transition phase Note : Each phase is concluded with a milestone - A point where critical decisions must be made. - Each phase has a specific purpose.
1.Inception Phase During inception establish the business case for the system and delimit the project scope. -Identify all external entities with which system will interact (actors) -Define the nature of the interaction at a high-level. -This involves identifying all use cases and describing a few significant ones. -The business case includes success criteria, risk assessment, and estimate of the resources needed, and a phase plan showing dates of major milestones.
The outcome of the inception phase is: Vision document : General vision of the core project's requirements, key features, and main constraints. A initial use-case model (10% -20%) complete) An initial project glossary (may optionally be partially expressed as a domain model). An initial business case, which includes business context, success criteria (revenue projection, market recognition, and so on), and financial forecast. An initial risk assessment. A project plan, showing phases and iterations. A business model, if necessary. One or several prototypes.
The evaluation criteria for the inception phase are: Stakeholder concurrence on scope definition and cost/schedule estimates. Requirements understanding as evidenced by the primary use cases. Credibility of the cost/schedule estimates, priorities, risks, and development process. Depth and breadth of any architectural prototype that was developed. Actual expenditures versus planned expenditures. The project may be cancelled or considerably re-thought if it fails to pass this milestone.
2.Elaboration Phase
Purpose is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the project. To accomplish these objectives, you must have the ³mile wide and inch deep´ view of the system. Architectural decisions have to be made with an understanding of the whole system: scope and major requirements. Elaboration phase is the most critical of the four phases. Here the hard ³engineering´ is considered complete and the project undergoes most important decision : whether or not to commit the project.
The elaboration phase activities ensure that the architecture, requirements and plans are stable enough, and the risks are sufficiently reduced. This predictably determines the cost and schedule for the completion of the development. Executable architecture prototype is built in one or more iterations, depending on the scope, size, risk, and novelty of the project.
The outcome of the elaboration phase is: A use-case model (at least 80% complete) ² all use cases and actors have been identified, and most usecase descriptions have been developed. Supplementary requirements capturing the non functional requirements and any requirements that are not associated with a specific use case. Software Architecture Description. An executable architectural prototype. A revised risk list and a revised business case. A development plan for the overall project, including the coarsegrained project plan, showing iterations´ and evaluation criteria for each iteration. An updated development case specifying the process to be used. A preliminary user manual (optional).
MileStone -The second important project milestone, the Lifecycle Architecture Milestone. -Here Examine the detailed system objectives and scope, the choice of architecture, and the resolution of the major risks.
3.Construction Phase
Here all features are thoroughly tested. Construction phase is, in one sense, a manufacturing process.. Managing resources and controlling operations to optimize costs, schedules, and quality. In other words, one of the critical qualities of the architecture is its ease of construction. The software product integrated on the adequate platforms. The outcome of the construction phase is a product ready to put in hands of its end users. It consists of: The user manuals. A description of the current release. Milestone : Initial Operational Capability Here you decide if the software, the sites, and the users are ready to go operational, without exposing the project to high risks
The evaluation criteria for the construction phase involve answering these questions: Is this product release stable and mature enough to be deployed ? Are all stakeholders ready for the transition into the user community? Are the actual resource expenditures versus planned expenditures still acceptable? Transition may have to be postponed by one release if the project fails to reach this milestone
4.Transition Phase
The transition phase focuses on the activities required to place the software into the hands of the users. Typically, this phase includes several iterations, including beta releases, general availability releases, as well as bug-fix and enhancement releases. Considerable effort is expended in developing user-oriented documentation, training users, supporting users in their initial product use, and reacting to user feedback. At this point in the lifecycle, however, user feedback should be confined primarily to product tuning, configuring, installation, and usability issues. The primary objectives of the transition phase include: Achieving user self-supportability Achieving stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision Achieving final product baseline as rapidly and cost effectively as practical This phase can range from being very simple to extremely complex, depending on the type of product.
At the end of the transition phase is the fourth important project milestone, the Product Release Milestone. At this point, you decide if the objectives were met, and if you should start another development cycle. In some cases, this milestone may coincide with the end of the inception phase for the next cycle. The primary evaluation criteria for the transition phase involve the answers to these questions: Is the user satisfied? Are the actual resources expenditures versus planned expenditures still acceptable?
Iterations Each phase in the Rational Unified Process can be further broken down into iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system. Compared to the traditional waterfall process, the iterative process has the following advantages: Risks are mitigated earlier Change is more manageable Higher level of reuse The project team can learn along the way Better overall quality Static Structure of the Process A process describes who is doing what, how, and when. The Rational Unified Process is represented using four primary modeling elements: Workers, the µwho¶ Activities, the µhow¶ Artifacts, the µwhat¶ Workflows, the µwhen¶
