Question

Differences between Classical and OO Architecture. in software engineering.

Answer 1

Introduction:

All software, especially large pieces of software produced by many people, should be produced using some kind of methodology. Even small pieces of software developed by one person can be improved by keeping a methodology in mind. A methodology is a systematic way of doing things. It is a repeatable process that we can follow from the earliest stages of software development through to the maintenance of an installed system. As well as the process, a methodology should specify what we‟re expected to produce as we follow the process. A methodology will also include recommendation or techniques for resource management, planning, scheduling and other management tasks. Good, widely available methodologies are essential for a mature software industry. A good methodology will address at least the following issues: Planning, Scheduling, Resourcing, Workflows, Activities, Roles, Artifacts, Education. There are a number of phases common to every development, regardless of methodology, starting with requirements capture and ending with maintenance. During the last few decades a number of software development models have been proposed and discussed within the Software Engineering community.

classical approach has a lot of models that deal with different types of projects such as waterfall, spiral, iterative and v-shaped, but all of them and other lack flexibility to deal with other kinds of projects like Object-Oriented. Object–oriented Software Engineering (OOSE) is an object modeling language and methodology.

The approach of using object – oriented techniques for designing a system is referred to as object–oriented design. Object–oriented development approaches are best suited to projects that will imply systems using emerging object technologies to construct, manage, and assemble those objects into useful computer applications. Object oriented design is the continuation of object-oriented analysis, continuing to center the development focus on object modeling techniques.

CLASSICAL ARCHITECTURE

There are a number of phases common to every development, regardless of methodology, starting with requirements capture and ending with maintenance. With the classical architecture, will be expected to move forward gracefully from one phase to the other. The list below describes the common phases in software development.

A. Requirements

Requirements capture is about discovering what is going to achieve with new piece of software and has two aspects. Business modeling involves understanding the context in which software will operate. A system requirement modeling (or functional specification) means deciding what capabilities the new software will have and writing down those capabilities .

B. Analysis

Analysis means understanding what are dealing with. Before designing a solution, it needs to be clear about the relevant entities, their properties and their inter-relationships. Also needs to be able to verify understanding. This can involve customers and end users, since they‟re likely to be subjectmatter experts .

C. Design

In the design phase, will work out, how to solve the problem. In other words, make decisions based on experience, estimation and intuition, about what software which will write and how will deploy it. System design breaks the system down into logical subsystems (processes) and physical subsystems (computers and networks), decides how machines will communicate, and chooses the right technologies for the job, and so on .

D. Specification

Specification is an often-ignored, or at least oftenneglected, phase. The term specification is used in different ways by different developers. For example, the output of the requirements phase is a specification of what the system must be able to do; the output of analysis is a specification of what are dealing with; and so on

E. Implementation

In this phase is writing pieces of code that work together to form subsystems, which in turn collaborate to form the whole system. The sort of the task which is carried out during the implementation phase is „Write the method bodies for the Inventory class, in such a way that they conform to their specification‟ .

F. Testing

When the software is complete, it must be tested against the system requirements to see if it fits the original goals. It is a good idea for programmers to perform small tests as they go along, to improve the quality of the code that they deliver .

G. Deployment

In the deployment phase, are concerned with getting the hardware and software to the end users, along with manuals and training materials. This may be a complex process, involving a gradual, planned transition from the old way of working to the new one

. H. Maintenance

When the system is deployed, it has only just been born. A long life stretches before it, during which it has to stand up to everyday use – this is where the real testing happens. The sort of the problem which is discovered discover during the maintenance phase is ,When the log-on window opens, it still contains the last password entered.' As the software developers, we normally interested in maintenance because of the faults (bugs) that are found in software. Must find the faults and remove them as quickly as possible, rolling out fixed versions of the software to keep the end users happy. As well as faults, users may discover deficiencies (things that the system should do but doesn‟t) and extra requirements (things that would improve the system)

OBJECT-ORIENTED ARCHITECTURE

In object-oriented Architecture, a system is viewed as a set of objects. All object-orientation experts agree that a good methodology is essential for software development, especially when working in teams. Thus, quite a few methodologies have been invented over the last decade. Broadly speaking, all object-oriented methodologies are alike – they have similar phases and similar artifacts – but there are many small differences. Object-oriented methodologies tend not to be too prescriptive: the developers are given some choice about whether they use a particular type of diagram, for example. Therefore, the development team must select a methodology and agree which artifacts are to be produced, before they do any detailed planning or scheduling. In general, each methodology addresses.

• The philosophy behind each of the phases.
• The workflows and the individual activities within each phase.
• The artifacts that should be produced (diagrams, textual descriptions and code).
• Dependencies between the artifacts.
• Notations for the different kinds of artifacts.
• The need to model static structure and dynamic behavior.

Static modeling involves deciding what the logical or physical parts of the system should be and how they should be connected together. Dynamic modeling is about deciding how the static parts should collaborate. Roughly speaking, static modeling describes how we construct and initialize the system, while dynamic modeling describes how the system should behave when it‟s running. Typically, we produce at least one static model and one dynamic model during each phase of the development. Some methodologies, especially the more comprehensive ones, have alternative development paths, geared to different types and sizes of development.The benefits of Object-Oriented Development are reduced time to market, greater product flexibility, and schedule predictability and the risks of them are performance and startup costs .

A. Analysis

The aim of the analysis process is to analyze, specify, and define the system which is to be built. In this phase, we build models that will make it easier for us to understand the system. The models that are developed during analysis are oriented fully to the application and not the implementation environment; they are "essential" models that are independent of such things as operating system, programming language, DBMS, processor distribution, or hardware configuration. Two different models are developed in analysis; the Requirements Model and the Analysis Model. These are based on requirement specifications and discussions with the prospective users. The first model, the Requirements Model, should make it possible to delimit the system and to define what functionality should take place within it. For this purpose we develop a conceptual picture of the system using problem domain objects and also specific interface descriptions of the system if it is meaningful for this system. We also describe the system as a number of use cases that are performed by a number of actors. The Analysis Model is an architectural model used for analysis of robustness. It gives a conceptual configuration of the system, consisting of various object classes: active controllers, domain entities, and interface objects. The purpose of this model is to find a robust and extensible structure for the system as a base for construction. Each of the object types has its own special purpose for this robustness, and together they will offer the total functionality that was specified in the Requirements Model. To manage the development, the Analysis Model may combine objects into Subsystems.

B. Construction

We build our system through construction based on the Analysis Model and the Requirements Model created by the analysis process. The construction process lasts until the coding is completed and the included units have been tested. There are three main reasons for a construction process:

1) The Analysis Model is not sufficiently formal.

2) Adaptation must be made to the actual implementation environment.

3) We want to do internal validation of the analysis results.

The construction activity produces two models, the Design Model and the Implementation Model. Construction is thus divided into two phases; design and implementation, each of which develops a model. The Design Model is a further refinement and formalization of the Analysis Model where consequences of the implementation environment have been taken into account. The Implementation model is the actual implementation (code) of the system.

C. Testing

Testing is an activity to verify that a correct system is being built. Testing is traditionally an expensive activity, primarily because many faults are not detected until late in the development. To do effective testing we must have as a goal that every test should detect a fault. Unit testing is performed to test a specific unit, where a unit can be of varying size from a class up to an entire subsystem. The unit is initially tested structurally, that is, "white box testing." This means that we use our knowledge of the inside of the unit to test it. We have various coverage criteria for the test, the minimum being to cover all statements. However, coverage criteria can be hard to define, due to polymorphism; many branches are made implicit in an object-oriented system. However, polymorphism also enhances the independence of each object, making them easier to test as standalone units. The use of inheritance also complicates testing, since we may need to retest operations at different levels in the inheritance hierarchy. On the other hand, since we typically have less code, there is less to test. Specification testing of a unit is done primarily from the object protocol (so-called "black box testing). Here we use equivalence partitioning to find appropriate test cases. Test planning must be done early, along with the identification and specification of tests .

D. UML

By the mid-1990s, the best-known methodologies were those invented by Ivar Jacobson, James Rumbaugh and Grady Booch. Each had his own consulting company using his own methodology and his own notation. By 1996, Jacobson and Rumbaugh had joined Rational Corporation, and they had developed a set of notations which became known as the Unified Modeling Language (UML). The „three amigos‟, as they have become known, donated UML to the Object Management Group (OMG) for safekeeping and improvement. OMG is a not-for-profit industry consortium, founded in 1989 to promote open standards for enterprise-level object technology; their other well-known work is CORBA .

1) Use Case Diagram

A use case is a static description of some way in which a system or a business is used, by its customers, its users or by other systems. A use case diagram shows how system use cases are related to each other and how the users can get at them. Each bubble on a use case diagram represents a use case and each stick person represents a user.

2) Class Diagram (Analysis Level)

A class diagram shows which classes exist in the business (during analysis) or in the system itself (during subsystem design).

3) Communication Diagram

A communication diagram, as its name suggests, shows collaborations between objects.

1) Deployment Diagram

A deployment diagram shows how the completed system will be deployed on one or more machines. A deployment diagram can include all sorts of features such as machines, processes, files and dependencies.

2) Class Diagram (Design Level)

The only difference is that design-level class diagrams tend to use more of the available notation, because they are more detailed. This one expands on part of the analysis class diagram to show methods, constructors and navigability.

3) Sequence Diagram

A sequence diagram shows interactions between objects. Communication diagrams also show interactions between objects, but in a way that emphasizes links rather than sequence. Sequence diagrams are used during subsystem design, but they are equally applicable to dynamic modeling during analysis, system design and even requirements capture.

COMPARISON BETWEEN CLASSICAL APPROACH AND OBJECT-ORIENTED APPROACH TO DEVELOPMENT IN SOFTWARE ENGINEERING

Classical Approach	Object-Oriented Approach
Used to develop the Traditional Projects that uses procedural programming.	Used to develop Object-oriented Projects that depends on ObjectOriented programming.
Uses common processes likes: analysis, design, implementation, and testing	Uses UML notations likes: use case, class diagram, communication diagram, development diagram and sequence diagram.
Depends on the size of projects and type of projects	Depends on the experience of the team and complexity of projects through the numbers of objects.
Needs to large duration sometimes to development the large projects.	Need to more time than Traditional approach and leads that to more cost.
classical approach uses classical life cycle	The object-oriented software life cycle identifies the three traditional activities of analysis, design, and implementation.

summary

1. As with any technology or tool invented by human beings, all SE methodologies have limitations .

2. The software engineering development has two ways to develop the projects that: classical approach and object oriented approach.

3. The classical approach uses traditional projects that used in development of their procedural programming like C, this approach leads software developers to focus on Decomposition of larger algorithms into smaller ones.

4. The object-oriented approach uses to development the object-oriented projects that use the object oriented programming like: C++ and Java.

5. The object-oriented approach to software development has a decided advantage over the classical approach in dealing with complexity and the fact that most contemporary languages and tools are object-oriented.

(please rate or comment)