OBJECT ORIENTED SOFTWARE ENGINEERING (OOSE)
A methodology for building and creating software systems based on the ideas of object-oriented programming (OOP) is known as object-oriented software engineering. The use of objects—which are simply instances of classes—to represent and control data and behaviour within a system is highlighted.
The following are some essential ideas and guidelines for object-oriented software engineering:
Classes and objects: Classes contain data (attributes) and behaviour (methods), and objects are instances of those classes. The structure and behaviour of objects are determined by classes.
Encapsulation: The idea of grouping data and methods into a class, masking internal workings, and presenting a clear interface for interacting with the object is known as encapsulation.
The ability to create new classes based on existing classes and inherit their characteristics and methods is known as inheritance. It encourages the development of hierarchies of classes with specialised functionality and the reuse of code.
Polymorphism: Polymorphism allows objects of several classes to be handled as though they were members of a single superclass. It enables the overriding of methods in subclasses, offering several implementations while maintaining the same interface.
A simplified representation of an object or set of objects that captures their fundamental features is known as abstraction. It ignores unimportant elements in favour of emphasising the key points.
Modularity is the separation of a system into more manageable, standalone modules. Each module needs to have a distinct function and clearly defined interfaces so that it may be independently developed and maintained.
The process of comprehending and establishing system requirements, recognising objects, and describing their relationships and behaviour is known as object-oriented analysis and design, or OOAD. It uses methods like class diagrams, sequence diagrams, state diagrams, and use case modelling.
Reusable solutions to frequently occurring issues in software design are known as design patterns. They offer tried-and-true methods for creating object-oriented systems and encourage best practises.
Object-oriented programming languages: Programming languages that enable OOP, such as Java, C++, C#, and Python, are frequently linked with object-oriented software engineering. Classes, objects, and their relationships can all be defined using the built-in features of these languages.
Developers can design modular, extendable software systems by using object-oriented software engineering ideas and practises. Because it encourages code reuse, flexibility, and scalability, it is a well-liked methodology in contemporary software development.
WHAT IS MODULE?
When a large product consists of a single monolithic block of code, maintenance is a nightmare. Even for the author of such a monstrosity, attempting to debug the code is extremely difficult; for another programmer to understand it is virtually impossible. The solution is to break the product into smaller pieces, called modules . What is a module? Is the way a product is broken into modules important in itself or is it important only to break a large product into smaller pieces of code? Stevens, Myers, and Constantine [1974] made an early attempt to describe modules. They defi ned a module as “a set of one or more contiguous program statements having a name by which other parts of the system can invoke it, and preferably having its own distinct set of variable names.” In other words, a module consists of a single block of code that can be invoked in the way that a procedure, function, or method is invoked. This defi nitionseems to be extremely broad. It includes procedures and functions of all kinds, whether
internal or separately compiled. It includes COBOL paragraphs and sections, even though they cannot have their own variables, because the defi nition states that the property of possessing a distinct set of variable names is merely “preferable.” It also includes modules nested inside other modules. But, broad as it is, the defi nition does not go far enough. For example, an assembler macro is not invoked and therefore, by the preceding defi nition, is not a module. In C and C++, a header fi le of declarations that is #included in a product similarly is not invoked. In short, this defi nition is too restrictive.
Yourdon and Constantine [1979] give a broader defi nition: “A module is a lexically contiguous sequence of program statements, bounded by boundary elements, having an aggregate identifi er.” Examples of boundary elements are begin . . . end pairs in a block- structured language like Pascal or {. . .} pairs in C++ or Java. This defi nition not only includes all the cases excluded by the previous defi nition but is broad enough to be used throughout this book. In particular, procedures and functions of the classical paradigm are modules. In the object-oriented paradigm, an object is a module and so is a method within an object.
To understand the importance of modularization, consider the following somewhat fanciful example. John Fence is a highly incompetent computer architect. He still has not discovered that both NAND gates and NOR gates are complete; that is, every circuit can be built with only NAND gates or with only NOR gates. John therefore decides to build arithmetic logic unit (ALU), shifter, and 16 registers using AND , OR , and NOT gates. The resulting computer is shown in Figure 7.1 . The three components are connected in a simple fashion. Now, our architect friend decides that the circuit should be fabricated on three silicon chips, so he designs the three chips shown in Figure 7.2 . One chip has all the gates of the ALU, a second contains the shifter, and the third is for the registers. At this point John
vaguely recalls that someone in a bar told him that it is best to build chips so that they have only one kind of gate, so he redesigns his chips. On chip 1 he puts all the AND gates, on chip 2 all the OR gates, and all the NOT gates go onto chip 3.
Cohesion:
Myers [1978b] defi ned seven categories or levels of cohesion. In the light of modern theoretical computer science, Myers’s fi rst two levels need to be interchanged because, as will be shown, informational cohesion supports reuse more strongly than functional cohesion.
The resulting ranking is shown in Figure 7.4 . This is not a linear scale of any sort. It is merely a relative ranking, a way of determining which types of cohesion are high (good) and which are low (bad). To understand what constitutes a module with high cohesion, it is necessary to start at the other end and consider the lower cohesion levels.
Coincidental Cohesion
A module has coincidental cohesion if it performs multiple, completely unrelated operations. An example of a module with coincidental cohesion is a module named print_the_next_line, reverse_the_string_of_characters_comprising_the_second_argument,
add_7_to_the_fi fth_argument, convert_the_fourth_argument_to_fl oating_point. An obvious question is, How can such modules possibly arise in practice? The most common cause is as a consequence of rigidly enforcing rules such as “every module shall consist of between 35 and 50 executable statements.” If a software organization insists that modules must be neither too big nor too small, then two undesirable things happen. First, two or more otherwise ideal smaller modules are lumped together to create a larger module with coincidental cohesion. Second, pieces hacked from well-designed modules that management considers too large are combined, again resulting in modules with coin-
cidental cohesion.
For BCA students click the following url you get OOSE notes according your syllabus
Comments