Object Oriented Development
The topic ‘Object Oriented Development’ consists of progressively developing a software application which would form a real world model of the business scenario. It gives a true picture of the real world entities and the association among them. It makes it quite understandable and readable in nature. Unlike the traditional software development environment, it portrays the real world instances of the atmosphere in connection to all the related internal and external entities.
The sections of this paper would outline and discuss the various process flow of the object oriented development environment and the phases that make it different from the other process models. The appropriate breakdown of the entire life cycle phase would make it acceptable and would provide a bird’s eye view to the entire process flow. The next section would highlight the various techniques the system analyst’s use for modeling their processes. The use of Use cases, class diagrams, state diagram, activity diagram, sequence diagrams and many more would be explained for their importance and relevance in depicting the business scenario.
Finally the merits and demerits of the technology are elaborated and discussed quite vividly. The amount of positive feedbacks it obtains along with the negative ones makes it quite well judged in the light of other software development paradigms. The conclusion takes care of the future of OOD and the better technologies which are posing a challenge. Chapter 2: What is OOD? Object Oriented Development (OOD) is the superb ability to represent complex relationships as well as to represent data and data processing with a consistent notation so that it is easily amendable at the analysis and design phase (Hoffer.
2002). The depiction of OOD is made with the help of diagrams which depict the business scenario and the very objective of the software to be built. The association of the various objects and their interaction is depicted with the help of those diagrams. Unlike the other software development paradigms, OOD makes sure that the dynamism in the behavior of the associated entities and the processes which they would be subjected to would be depicted quite distinctly in nature so that it gets a whole new meaning to the design phase.
The various features of the OOD which makes the development environment distinguishable are the following: • Abstraction: The entire concept of abstraction is hiding the view and access of data from the outside world so that it does not face accidental or intentional alteration. The program data and elements are hidden from outside access so that the user has no role to play in either viewing it or changing them to get desirable results. This feature makes the OOD process unique to other development strategies. • Encapsulation: The wrapping up of data and functions into a single unit called class is termed as encapsulation.
It provides the mechanism of holding the program elements so that instances can be drawn easily and we can work better. OOD makes it quite feasible to envelope all the associated information of an entity into one single unit called the class. • Inheritance and Reusability: Inheriting the traits of the parent entity, so that the child does not require redefining all the common characteristics is known as Inheritance. The reusability factor would make fewer codes to be written and existing codes to be used. • Polymorphism: The entire concept of polymorphism is the ability to take another form.
The existing objects can be used for various functionalities which makes it quite distinct than the other forms of development strategies. Chapter 3: Characteristics of OOD: 1. Object-oriented analysis, design and programming are related but distinct. 2. OOA is more apprehensive with constructing an object model of the application domain. 3. OOD takes into account the development of an object oriented system model to take care of requirements. 4. The objects provide abstractions and are real-world entities and the functions enable it to manage them. 5.
The objects are independent which summarize state and version information. 6. System functionality is expressed in terms of object services. 7. Shared data areas are eliminated. Objects communicate by message passing. 8. Objects may be distributed and may execute sequentially or in parallel. The magic of the different types of diagrams makes the depiction quite vibrant in nature. The following are some of those: Chapter 4: Unified Modeling Language UML is a language for specifying, visualizing and constructing the artifacts of software systems, as well as for business modeling (UML Document Set, 1995).
The Use case diagram takes the form of such a modeling language. Figure 2: UML Class diagram It consists of the following: Sequence Diagrams: It depicts the order of interactions which takes place among the objects (Pressman, 2005). Objects are arranged horizontally across the top; Time is represented vertically so models are read top to bottom; Interactions are represented by labeled arrows, Different styles of arrow represent different types of interaction; A thin rectangle in an object lifeline represents the time when the object is the controlling object in the system.
Figure 3: Sequence Diagram An Object Oriented design depicts the whole system as a real world model. The components are as follows: The subsystem Layer: It contains a representation of each of the subsystems that enable the software to achieve its customer-defined requirements and to implement the technical infrastructure that supports customer requirements. The class and object layer: It contains the class hierarchies that enable the system to be created using generalizations and increasingly more targeted specializations. This layer also contains representations of each object.
The message layer: It contains the design details that enable each object to communicate with its collaborators. This layer establishes the external and internal interfaces for the system. The responsibilities layer: It contains the data structure and algorithmic design for all attributes and operations for each object (Coad, 2001). The Object Oriented design is complete as it envelopes to a large extent the real life problems and scenarios and captures every entity in the environment and maps the critical relationships among the entities and data communication among them (Jacobson, 2002).
Chapter 5: How does OOD help organizations in software development environment? OOD stands quite ideal for representing the real world scenario which would most appropriately be interpreted by all levels of people in the software development team and also the requirements can be mapped distinctly to represent the business situation. The process to be followed is defined in the coming sections which make the development atmosphere quite distinct. The following are the development phases which are undertaken when the software passes through the developmental phases to develop into a deliverable:
• In the OOD analysis phase, a model of the real-world application is developed showing its essential properties. Figure 4 : OOD Cycle The model specifies the functional behavior of the system. • In the OOD design phase, the definition as to the ‘how’ the application-oriented analysis model will be realized in the implementation environment. It requires identification and investigation of the consequences the implementation environment will have on the design (Pressman, 2003). • Implementation of the OOD would be in programming languages which supports all the features of the OOPS concepts and methods.
The database also would be designed in the similar manner so as to keep in synchronization with the front end interface. The reason as to which the OOD must be favored by any organization are as follows: • Unlike other paradigms or models where the analysis model is directly implemented with the programming language. OOD moves seemingly into the source code after refining the objects and making prior decisions on what operations an object will provide. The inter-object communication is well defined in OOD which clearly depicts the messages to be passed and so forth.
• The actual system must be adapted to the environment in which the system will actually be implemented. To accomplish that, the analysis model has to be transformed into a design model, considering the other factors. • The OOD analysis results can be validated using object-oriented design. At this stage, the results are verifiable with the analysis model. The greater understanding and skill in operation steps would make the process to be monitored evenly so that everything is done rightly in the first instance. Chapter 6: Merits and Demerits of OOD?
Object Oriented Design (OOD) methodologies primarily have two key strengths. First, they do an excellent job of supporting COTS and reuse (Rickman, 2000). OOD is basically a bottom up approach where you are able to view the system as a set of objects that can be departmentalized to form a system. The OOD approach inherently makes software’s object a standalone component that can be reused with a variety of problem domains thus providing the unexplored problem complexity into a feasible state for analysis and development.
Coad and Yourdon (1991) identifies the merits of the OOD paradigm to be as follows: • The ability to tackle more challenging problem domains • Improved communication among users, analysts, designers and programmers. • Increased consistency among analysis, design and programming activities. • Explicit representation of commonality among system components. • Robustness of systems. • Reusability of analysis, design and programming results, • Increased consistency among all the models developed during object-oriented analysis, design and programming.
• Easier maintenance. Objects can be understood as standalone entities. • Provides an insight into data relationships and associations. The demerits of OOD are as follows: 1. Lack of a System Functional Model : The OOD only creates functional model within the objects and not the entire system. This is the biggest drawback of the OOD where it has equal opportunity to miss some crucial requirements in the design process. 2. System performance and sizing is difficult: The OOD model does not easily describe the associations and communications between objects.
However, the basic concept of OOD is that the object need not know who is invoking it and how the messages are exchanged. While this leads to a flexible design, performance modeling cannot be handled readily. 3. Identification objects is week: The OOD methodology by itself does not provide support for identifying which objects will generate an optimal system design. Specifically, there is no single diagram that shows all of the interfaces between objects. Since coupling is a major factor in system complexity, not having this information makes architecture component selection a hit or miss proposition (Rickman, 2000).
Conclusion: OOD would make the system development strategy makes a great and sound impact to the development paradigms. It makes it quite real to the prevailing conditions of the business scenario which would be analyzed and designed to develop the system. The very use of the different diagrams discussed makes the system description and illustration more generalized in nature and easily makes it able to model. The various diagrams are for different problem domains and representing the situation according to the prevailing conditions. References/ Bibliography Coad, P. , and E.
Yourdon (1991). Object-Oriented Design. Englewood Cliffs, NJ: Prentice hall. Booch, G. (1994). Object-Oriented analysis and Design with Application. 2nd Ed. Redwood City, CA. Hoffer A. Jeffery (2002). Modern Systems Analysis and Design, Pearson Education. Jacobson, I (1992). Object-Oriented Software Engineering: A use case driven approach, Addison-Wesley. Silvia, T Acu (2000). A Process model applicable to Software engineering and knowledge Engineering. Sommerville, Ian (2003). Software Engineering. Pearson UML Document Set (1997). Santa Clara: Rational Software Corporation.
Sample Essay of StudyFaq.com