Note: Sample below may appear distorted but all corresponding word document files contain proper formattingExcerpt from Term Paper:
object-oriented (OO) and component-based development. It begins by describing the evolution of the abstraction process and the emergence of OO programming. Next, the limitations of OO programming are discussed along with an explanation of how component-based development was born to serve as a complimentary extension to OO to overcome its primary disadvantages. Given the differences between objects and components, this paper makes recommendations for developing systems using both constructs. Finally, the future of objects and components is discussed.
Assembly languages started the abstraction process by coding the binary-based machine code, or pulse train of successive 0s and 1s, into assemblies representing particular machine code sequences (Hoagland). Next, higher level languages made coding closer to human readable. The language and its compilers were coordinated such that the output would give a computational valid result. OO programming raised the level of abstraction in programming even further. OO programming is a programming language model organized around "objects" rather than "actions" and data rather than logic.
According to object-oriented experts Atkinson, Altair, DeWitt, Dittrich, Maier, and Zdonik (1989), an object oriented system has eight main features: complex objects, object identity, encapsulation, types and classes, inheritance, overriding combined with late binding, extensibility and computational completeness defined as:
Complex objects are built from simpler ones by applying constructors to them. The simplest objects are objects such as integers, characters, byte strings of any length, booleans and floats (one might add other atomic types). There are various complex object constructors: tuples, sets, bags, lists, and arrays are examples
Object identity means an object has an existence which is independent of its value
Encapsulation satisfies the need to cleanly distinguish between the specification and the implementation of an operation and the need for modularity.
A type, in an object-oriented system, summarizes the common features of a set of objects with the same characteristics. Class is more of a run-time notion. It contains two aspects: an object factory which can be used to create new objects and an object warehouse. The object warehouse means that attached to the class is the set of objects that are instances of the class. The user can manipulate the warehouse by applying operations on all elements of the class.
Inheritance is a powerful modeling that that provides a concise and precise description of the world and it helps in factoring out shared specification and implementations in applications.
Overriding is the redefinition of the implementation of the operation for each of the types according to the type. The system cannot bind operation names to programs at compile time. Therefore, operation names must be resolved at run-time. This delayed translation is called late binding.
Extensibility means that one can define new types and there is no distinction in usage between system defined and user defined types. Computational completeness means that one can express any computable function, using the data modeling language of the database system.
One of the largest contributions of OO programming has been the success of developmental frameworks, the expression of operational polymorphism in sets of system classes, grouped into collections called libraries, such as Microsoft Foundation Classes, that supply to applications basic system functionality, such as visual interface elements and stacks (Hoagland).
However, OO programming has only been a modest success to date for a variety of reasons. For one, skills are not available in the typical IT organization to leverage this complex technology (Hurwitz, 1998). For example, inheritance requires that developers know exactly what they are inheriting. Thus, it is very easy for the developer to make a mistake. The developer is expected to select from libraries of hundreds or thousands of existing objects to create complex applications. This process is very confusing. It can be difficult to find the right object for the right task and to distinguish between objects that perform similar functions. And, the full benefits of OO programming were never fully realized, partly because implementation inheritance defeated true encapsulation (Hoagland). Also, OO programming has never fully fulfilled its promise of much greater code reuse. The high cost of software creation and the failure to follow good coding practices contributed to the rise of software components and component-based development. It success in the market has been largely due to the advent of the distributed era of computing with its demand for truly encapsulated code to be delivered on a much shorter time frame.
Component software represents the extension of OO programming as described below (Hoagland):
Object technology has brought to light -- and tried to free us from -- the limitations of the traditional view of a program as an executable that does one thing. Beyond this simple view, object technology introduces the notion of class, providing a number of well-specified operations (commands and queries) on a certain data abstraction. We can take a program and make it into a component, but unless it is a trivial one-input/one-output program, we will need to "componentize" it: Wrap it into a hull, with a set of openings providing to the rest of the world the set of operations that we expect the program to perform for us on request."
Thus, OO programming involves constructing a new system in terms of interacting, distinct units of information and services called objects while component-based programming involves constructing new systems from already existing, service-providing components (Petre, 2000). Both components and objects:
have encapsulation properties are accessed via well-defined interfaces are considered to improve the reuse of software are considered to alleviate the software evolution phase are thought of being natural abstractions of real-world entities allow a real-world entity to be modelled/implemented
During development, a component translates more or less to a collection of objects (Henderson-Sellers, Pradhan, Szyperski, Taivalsaari and Wills). A developer is able to use the same concepts of objects, object relationships, object stereotypes etc. And apply them successfully to a 'group of objects' or a component. Patterns, which can be applied to create components, can also be used to create a group of objects. Thus, during development, components and objects are not much different, except for the fact that a component is a collection of objects. However, at runtime, a single instance of a component is instantiated at a nearby or far away server to provide all the functionality expected of the component through its interface. Objects, on the other hand, can be instantiated multiple times, and may reside on one or more machines. Thus, there appears to be a distinct difference between what is called a component (a single runtime entity providing all functionality) and an object (of which multiple copies can be instantiated, and which may go in and out of scope during the execution of a thread of sequence).
There are also other differences between components and objects. One is the division of labor (Hurwitz, 1998). Components create two classes of developers. The first group of developers are highly skilled developers who can use all the power of objects to create fine-grained objects that they then string together to create large-grained business-oriented components. The second group is the traditional corporate developers who do not know how to program in complex object-oriented languages. These developers use components created by the more skilled developers. The corporate programmer is not allowed to change the component's content. Thus, a coarse-grained component does not allow inheritance to be applied, which protects the integrity of the component and helps prevent mistakes.
Components also offer a higher level of abstraction than objects (Henderson-Sellers, Pradhan, Szyperski, Taivalsaari and Wills). Objects form abstractions over identifiable parts of a state space: they have a unique identity and they encapsulate the variables and operations over those variables that define the abstracted part of the state space. Hence, no two objects occupy the same partition of the universal state space. Components form abstractions over namable parts of a deployment space: they have a name but not a unique identity; they encapsulate static implementation decisions and are restricted to explicitly specified dependencies on other components only and, preferably, have dependencies that are configurable. Components are coarse-grained pieces of application code with well-defined APIs (Hurwitz, 1998). With components encapsulation becomes one of the foremost techniques for leveraging existing code so that it can be reused on a consistent basis in a new applications environment. In most "pure" object-oriented systems, very little use is made of existing code from pre-built older systems. In the component model, encapsulation is a fundamental building block. Organizations can select key pieces of logic from an older system and encapsulate them as business objects or components to be used within existing systems.
Another key difference between objects and components is focus (Hurwitz, 1998). While objects tend to be focused on the technical functions they provide, coarse-grained components are focused on the business task. For example, a financial organization might implement a component called "30-year mortgage calculations," and a manufacturing company may have a component called "cost to produce yellow napkins." Thus, it is very easy to determine which service each of these components is intended to provide.…[continue]
"Component-Based Development How Is It Different From Oo Development" (2003, November 28) Retrieved October 22, 2016, from http://www.paperdue.com/essay/component-based-development-how-is-it-different-158651
"Component-Based Development How Is It Different From Oo Development" 28 November 2003. Web.22 October. 2016. <http://www.paperdue.com/essay/component-based-development-how-is-it-different-158651>
"Component-Based Development How Is It Different From Oo Development", 28 November 2003, Accessed.22 October. 2016, http://www.paperdue.com/essay/component-based-development-how-is-it-different-158651
IEEE-Computer Science -- Literature Review IEEE-Computer Science Integration Approaches Practices The work of Ziegler and Dittrich (nd) reports that integration is "becoming more and more indispensable in order not to drown in data while starving for information." The goal of data integration is "to combine data from different sources by applying global data model and by detecting and resolving schema and data conflicts so that a homogenous, unified view can be provided." (Ziegler
Risk Management in Hedge Funds
A research of how dissimilar hedge fund managers identify and achieve risk
As the business changes, developers can more easily map business process changes to applications and then implement the appropriate it changes. SOA facilitates business connections. With business processes packaged as modular, accessible business services, enterprises can connect them where and when they are needed to optimize processes across customers, partners, suppliers, and their own internal applications SOA enhances business control. Because services model business processes, the flow of data and transactions
Strategic Planning for Companies Strategic Planning for Cincom Systems Creating transformational change in companies by automating their most challenging processes, strategies and systems is what Cincom Systems excels at today. The company has five different product divisions, each selling enterprise software into various segments of the Customer Relationship Management (CRM) marketplace. Privately held with 700 employees employed across five continents, Cincom is also profitable and has had many customers on maintenance contracts
The reward for the effort of learning is access to a vocabulary that is shared by a very large population across all industries globally" (p. 214). Moreover, according to Bell, because UML is a language rather than a methodology, practitioners who are familiar with UML can join a project at any point from anywhere in the world and become productive right away. Therefore, Web applications that are built using
Extensible Markup Language (XML) was born in the height of the browser wars in the mid-1990's. As Microsoft, Netscape, and W3C produced new and better versions of HTML. Jon Bosak, of Sun Microsystems, started the W3C SGML working group. Before long this name was changed to XML and the light cousin of SGML was born. Since that time XML has become a major server side resource for web site presentations. The