Comparison Between Traditional Approach And Object .
(IJACSA) International Journal of Advanced Computer Science and Applications,Vol. 2, No. 6, 2011Comparison between Traditional Approach andObject-Oriented Approach in Software EngineeringDevelopmentNabil Mohammed Ali Munassar 1Dr. A. Govardhan 2PhD Student 3rd year of Computer Science & EngineeringJawaharlal Nehru Technological UniversityKuktapally, Hyderabad- 500 085, Andhra Pradesh, IndiaProfessor of Computer Science & EngineeringPrincipal JNTUH of Engineering College, Jagityal,Karimnagar (Dt), A.P., IndiaAbstract— This paper discusses the comparison betweenTraditional approaches and Object-Oriented approach.Traditional approach has a lot of models that deal withdifferent types of projects such as waterfall, spiral, iterative andv-shaped, but all of them and other lack flexibility to deal withother kinds of projects like Object-Oriented.Object–oriented Software Engineering (OOSE) is an objectmodeling language and methodology. The approach of usingobject – oriented techniques for designing a system is referred toas object–oriented design. Object–oriented developmentapproaches are best suited to projects that will imply systemsusing emerging object technologies to construct, manage, andassemble those objects into useful computer applications. Objectoriented design is the continuation of object-oriented analysis,continuing to center the development focus on object modelingtechniques.Keywordss- Software Engineering; Traditional Approach;Object-Oriented Approach; Analysis; Design; Deployment; Test;methodology; Comparison between Traditional Approach andObject-Oriented Approach.I.INTRODUCTIONAll software, especially large pieces of software producedby many people, should be produced using some kind ofmethodology. Even small pieces of software developed by oneperson can be improved by keeping a methodology in mind. Amethodology is a systematic way of doing things. It is arepeatable process that we can follow from the earliest stagesof software development through to the maintenance of aninstalled system. As well as the process, a methodology shouldspecify what we‟re expected to produce as we follow theprocess. A methodology will also include recommendation ortechniques for resource management, planning, scheduling andother management tasks. Good, widely availablemethodologies are essential for a mature software industry.A good methodology will address at least the followingissues: Planning, Scheduling, Resourcing, Workflows,Activities, Roles, Artifacts, Education. There are a number ofphases common to every development, regardless ofmethodology, starting with requirements capture and endingwith maintenance. During the last few decades a number ofsoftware development models have been proposed anddiscussed within the Software Engineering community. Withthe traditional approach, you‟re expected to move forwardgracefully from one phase to the other. With the modernapproach, on the other hand, you‟re allowed to perform eachphase more than once and in any order [1, 10].II. TRADITIONAL APPROACHThere are a number of phases common to everydevelopment, regardless of methodology, starting withrequirements capture and ending with maintenance. With thetraditional approach, will be expected to move forwardgracefully from one phase to the other. The list below describesthe common phases in software development [1, 6].A. RequirementsRequirements capture is about discovering what is going toachieve with new piece of software and has two aspects.Business modeling involves understanding the context in whichsoftware will operate. A system requirement modeling (orfunctional specification) means deciding what capabilities thenew software will have and writing down those capabilities [1].B. AnalysisAnalysis means understanding what are dealing with.Before designing a solution, it needs to be clear about therelevant entities, their properties and their inter-relationships.Also needs to be able to verify understanding. This can involvecustomers and end users, since they‟re likely to be subjectmatter experts [1].C. DesignIn the design phase, will work out, how to solve theproblem. In other words, make decisions based on experience,estimation and intuition, about what software which will writeand how will deploy it. System design breaks the system downinto logical subsystems (processes) and physical subsystems(computers and networks), decides how machines willcommunicate, and chooses the right technologies for the job,and so on [1].D. SpecificationSpecification is an often-ignored, or at least oftenneglected, phase. The term specification is used in differentways by different developers. For example, the output of therequirements phase is a specification of what the system mustbe able to do; the output of analysis is a specification of whatare dealing with; and so on [3].70 P a g ewww.ijacsa.thesai.org
(IJACSA) International Journal of Advanced Computer Science and Applications,Vol. 2, No. 6, 2011E. ImplementationIn this phase is writing pieces of code that work together toform subsystems, which in turn collaborate to form the wholesystem. The sort of the task which is carried out during theimplementation phase is „Write the method bodies for theInventory class, in such a way that they conform to theirspecification‟ [5].F. TestingWhen the software is complete, it must be tested against thesystem requirements to see if it fits the original goals. It is agood idea for programmers to perform small tests as they goalong, to improve the quality of the code that they deliver [5].G. DeploymentIn the deployment phase, are concerned with getting thehardware and software to the end users, along with manualsand training materials. This may be a complex process,involving a gradual, planned transition from the old way ofworking to the new one [1].H. MaintenanceWhen the system is deployed, it has only just been born. Along life stretches before it, during which it has to stand up toeveryday use – this is where the real testing happens. The sortof the problem which is discovered discover during themaintenance phase is „When the log-on window opens, it stillcontains 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 andremove them as quickly as possible, rolling out fixed versionsof the software to keep the end users happy. As well as faults,users may discover deficiencies (things that the system shoulddo but doesn‟t) and extra requirements (things that wouldimprove the system) [3, TestFigure 1: The linear Sequential Model [6].III. OBJECT-ORIENTED APPROACHIn object-oriented approach, a system is viewed as a setof objects. All object-orientation experts agree that a goodmethodology is essential for software development, especiallywhen working in teams. Thus, quite a few methodologies havebeen invented over the last decade. Broadly speaking, allobject-oriented methodologies are alike – they have similarphases and similar artifacts – but there are many smalldifferences. Object-oriented methodologies tend not to be tooprescriptive: the developers are given some choice aboutwhether they use a particular type of diagram, for example.Therefore, the development team must select a methodologyand agree which artifacts are to be produced, before they doany detailed planning or scheduling. In general, eachmethodology addresses: The philosophy behind each of the phases.The workflows and the individual activities withineach 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 dynamicbehavior.Static modeling involves deciding what the logical orphysical parts of the system should be and how they should beconnected together. Dynamic modeling is about deciding howthe static parts should collaborate. Roughly speaking, staticmodeling describes how we construct and initialize the system,while dynamic modeling describes how the system shouldbehave when it‟s running. Typically, we produce at least onestatic model and one dynamic model during each phase of thedevelopment.Some methodologies, especially the more comprehensiveones, have alternative development paths, geared to differenttypes and sizes of development.[1,4]The benefits of Object-Oriented Development are reducedtime to market, greater product flexibility, and schedulepredictability and the risks of them are performance and startup costs [5].A. AnalysisThe aim of the analysis process is to analyze, specify, anddefine the system which is to be built. In this phase, we buildmodels that will make it easier for us to understand the system.The models that are developed during analysis are orientedfully to the application and not the implementationenvironment; they are "essential" models that are independentof such things as operating system, programming language,DBMS, processor distribution, or hardware configuration.Two different models are developed in analysis; theRequirements Model and the Analysis Model. These are basedon requirement specifications and discussions with theprospective users. The first model, the Requirements Model,should make it possible to delimit the system and to definewhat functionality should take place within it.Forthis purpose we develop a conceptual picture of the systemusing problem domain objects and also specific interfacedescriptions of the system if it is meaningful for this system.We also describe the system as a number of use cases that areperformed by a number of actors. The Analysis Model is anarchitectural model used for analysis of robustness. It gives aconceptual configuration of the system, consisting of variousobject classes: active controllers, domain entities, and interfaceobjects. The purpose of this model is to find a robust andextensible structure for the system as a base for construction.Each of the object types has its own special purpose for thisrobustness, and together they will offer the total functionalitythat was specified in the Requirements Model. To manage thedevelopment, the Analysis Model may combine objects intoSubsystems [2].71 P a g ewww.ijacsa.thesai.org
(IJACSA) International Journal of Advanced Computer Science and Applications,Vol. 2, No. 6, 2011B. ConstructionWe build our system through construction based on theAnalysis Model and the Requirements Model created by theanalysis process. The construction process lasts until the codingis completed and the included units have been tested. There arethree main reasons for a construction process:1) The Analysis Model is not sufficiently formal.2) Adaptation must be made to the actualimplementation environment.3) We want to do internal validation of the analysisresults.The construction activity produces two models, the DesignModel and the Implementation Model. Construction is thusdivided into two phases; design and implementation, each ofwhich develops a model. The Design Model is a furtherrefinement and formalization of the Analysis Model whereconsequences of the implementation environment have beentaken into account. The Implementation model is the actualimplementation (code) of the system. [2].1) Use Case DiagramA use case is a static description of some way in which asystem or a business is used, by its customers, its users or byother systems. A use case diagram shows how system use casesare related to each other and how the users can get at them.Each bubble on a use case diagram represents a use case andeach stick person represents a user. Figure 2 depicts a car rentalstore accessible over the Internet. From this picture, we canextract a lot of information quite easily. For example, anAssistant can make a reservation; a Customer can look for carmodels; Members can log on; users must be logged on beforethey can make reservations; and so on [1, 3].C. TestingTesting is an activity to verify that a correct system is beingbuilt. Testing is traditionally an expensive activity, primarilybecause many faults are not detected until late in thedevelopment. To do effective testing we must have as a goalthat every test should detect a fault.Unit testing is performed to test a specific unit, where a unitcan be of varying size from a class up to an entire subsystem.The unit is initially tested structurally, that is, "white boxtesting." This means that we use our knowledge of the inside ofthe unit to test it. We have various coverage criteria for the test,the minimum being to cover all statements. However, coveragecriteria can be hard to define, due to polymorphism; manybranches are made implicit in an object-oriented system.However, polymorphism also enhances the independence ofeach object, making them easier to test as standalone units. Theuse of inheritance also complicates testing, since we may needto retest operations at different levels in the inheritancehierarchy. On the other hand, since we typically have less code,there is less to test. Specification testing of a unit is doneprimarily from the object protocol (so-called "black boxtesting). Here we use equivalence partitioning to findappropriate test cases. Test planning must be done early, alongwith the identification and specification of tests [2].D. UMLBy the mid-1990s, the best-known methodologies werethose invented by Ivar Jacobson, James Rumbaugh and GradyBooch. Each had his own consulting company using his ownmethodology and his own notation. By 1996, Jacobson andRumbaugh had joined Rational Corporation, and they haddeveloped a set of notations which became known as theUnified Modeling Language (UML). The „three amigos‟, asthey have become known, donated UML to the ObjectManagement Group (OMG) for safekeeping and improvement.OMG is a not-for-profit industry consortium, founded in 1989to promote open standards for enterprise-level objecttechnology; their other well-known work is CORBA [1].Figure 2: A use Case Diagram2)Class Diagram (Analysis Level)A class diagram shows which classes exist in the business(during analysis) or in the system itself (during subsystemdesign). Figure 3 shows an example of an analysis-level classdiagram, with each class represented as a labeled box. As wellas the classes themselves, a class diagram shows how objectsof these classes can be connected together. For example, Figure3 shows that a CarModel has inside it a CarModelDetails,referred to as its details.U3: View Car Model Details. (ExtendsU2, extended by U7.) Preconditions: None.a) Customer selects one of the matching Car Models.b) Customer requests details of the selected Car Model.c) iCoot displays details of the selected Car Model(make, engine size, price, description, advert andposter).d) If Customer is a logged-on Member, extend with U7.Postconditions: iCoot has displayed details of selected CarModels.Nonfunctional Requirements: r1. Adverts should bedisplayed using a streaming protocol rather than requiring adownload [1, 5].72 P a g ewww.ijacsa.thesai.org
(IJACSA) International Journal of Advanced Computer Science and Applications,Vol. 2, No. 6, 2011Figure 4: A communication DiagramFigure 3: A class Diagram at the Analysis Level.3) Communication DiagramA communication diagram, as its name suggests, showscollaborations between objects. The one shown in Figure 4describes the process of reserving a car model over the Internet:A Member tells the MemberUI to reserveaCarModel; the MemberUI tells the ReservationHome to createa Reservation for the given CarModel and the current Member;the MemberUI then asks the new Reservation for its numberand returns this to the Member [1].1) Deployment DiagramA deployment diagram shows how the completed systemwill be deployed on one or more machines. A deploymentdiagram can include all sorts of features such as machines,processes, files and dependencies. Figure 5 shows that anynumber of HTMLClient nodes (each hosting a Web Browser)and GUIClient nodes communicate with two server machines,each hosting a WebServer and a CootBusinessServer; eachWeb Server communicates with a CootBusinessServer; andeach CootBusinessServer communicates with a DBMS runningon one of two DBServer nodes [1].Figure 5: A deployment Diagram.2)Class Diagram (Design Level)The class diagram shown in Figure 6 uses the same notationas the one introduced in Figure 3. The only difference is thatdesign-level class diagrams tend to use more of the availablenotation, because they are more detailed. This one expands onpart of the analysis class diagram to show methods,constructors and navigability [1, 3].73 P a g ewww.ijacsa.thesai.org
(IJACSA) International Journal of Advanced Computer Science and Applications,Vol. 2, No. 6, 2011Figure 7: A sequence Diagram from the Design PhaseIV.COMPARISON BETWEEN TRADITONAL APPROACH ANDOBJECT-ORIENTED APPROACH TO DEVELOPMENT INSOFTWARE ENGINEERINGSummarize the comparison between Traditional Approachand Object-Oriented Approach shows through the table1.TABLE 1. COMPARISON BETWEEN TRADITIONAL APPROACH AND OBJECTORIENTED APPROACHTABLE I.Figure 6: A design-level Class Diagram3)Sequence DiagramA sequence diagram shows interactions between objects.Communication diagrams also show interactions betweenobjects, but in a way that emphasizes links rather thansequence. Sequence diagrams are used during subsystemdesign, but they are equally applicable to dynamic modelingduring analysis, system design and even requirements capture.The diagram in Figure 7 specifies how a Member can log offfrom the system. Messages are shown as arrows flowingbetween vertical bars that represent objects (each object isnamed at the top of its bar). Time flows down the page on asequence diagram. So, Figure 7 specifies, in brief: a enticationServlet passes the request on to theAuthenticationServer, reading the id from the browser session;the AuthenticationServer finds the corresponding Memberobject and tells it to set its session id to 0; the Member passesthis request on to its InternetAccount; finally, the Member ispresented with the home page [1, 5].Traditional ApproachObject-Oriented ApproachUsed to develop theTraditional Projects that usesprocedural programming.Used to develop Object-orientedProjects that depends on ObjectOriented programming.Uses UML notations likes: use case,class diagram, communicationdiagram, development diagram andsequence diagram.Depends on the experience of theteam and complexity of projectsthrough the numbers of objects.Need to more time than Traditionalapproach and leads that to morecost.Uses common processeslikes: analysis, design,implementation, and testing.Depends on the size ofprojects and type of projects.Needs to large durationsometimes to developmentthe large projects.The problem of Traditionalapproach using classical lifecycle [7, 8].The object-oriented software lifecycle identifies the three traditionalactivitiesof analysis, design, andimplementation.[8].74 P a g ewww.ijacsa.thesai.org
(IJACSA) International Journal of Advanced Computer Science and Applications,Vol. 2, No. 6, 20114.5.Large ProjectsMedium ProjectsSmall ralModelXP ModelFinally, some topics can be suggested for future works:Figure 8: Illustrate The Different Models of Traditional Approach withDifferent Projects. [1, 6, 11]1.From the previous figure 8 which illustrates the fivemodels from traditional approach that deals with three types ofprojects, where we notice the waterfall model deals properlywith large and medium projects like spiral model and iterativemodel that needs more time more cost and experience for team,however the V-shape model and XP model use properly withmedium and small projects, because they need little time andsome experience of team to perform projects.9080706050403020100Traditiona ike O‟Docherty, "Object-Oriented Analysis and Design UnderstandingSystem Developmentwith UML 2.0", John Wiley & Sons Ltd,England, 2005.[2] Magnus Christerson and Larry L. Constantine, “Object-OrientedSoftware Engineering- A Use Case Driven Approach “, ObjectiveSystems, Sweden, 2009.[3] Ian sommerville, “Software Engineering”, Addison Wesley, 7th edition,2004.[4] Pankaj Jalote, “An Integrated Approach to Software Engineering”,Springer Science Business Media, Inc, Third Edition, 2005.[5] Grady Booch, “Object-Oriented Analysis and Design with applications”,Addison Wesley Longman, Inc, second Edition, 1998.[6] Roger S. Pressman, “Software Engineering a practitioner‟s approach”,McGraw-Hill, 5th edition, 2001.[7] M M Lehman,”Process Models, Process Programs, ProgrammingSupport”, ACM, 1987.[8] Tim Korson and John D. McGregor,” Understanding Object-Oriented: AUnifying Paradigm”, ACM, Vol. 33, No. 9, 1990.[9] Li Jiang and Armin Eberlein,” Towards A Framework for Understandingthe Relationships between Classical Software Engineering and AgileMethodologies“, ACM, 2008.[10] Luciano Rodrigues Guimarães and Dr. Plínio Roberto Souza Vilela,”Comparing Software Development Models Using CDM”, ACM, 2005.[11] Alan M. Davis and Pradip Sitaram, “A Concurrent Process Model ofSoftware Development”, ACM, Software Engineering Notes Vol. 19 No.2, 1994.CONCLUSION AND FUTURE WORKAUTHORS PROFILENabil Mohammed Ali MunassarAfter completing this paper, it is concluded that:2.3.REFERENCESFrom the previous chart illustrates the some criteria suchas (Complexity, Experience, and Cost). In TraditionalApproach this criterion depends on the type of model and sizeof project, but in general as shows from figure 9 is little abovefrom the middle, however the Object-Oriented Approachdepends on the complexity of project that leads to increase thecost than other approach.1.2.Design the model that includes the features oftraditional approach and object-oriented approach todevelop and deals with different projects in softwareengineering.Updating some traditional approach to be able to usedifferent types of projects.Simplifying the object-oriented approach through itssteps to use the smallest projects that deal with simpleprogramming.[1]Figure 9: Illustrate The Different Criteria (Complexity, Experience and Cost)for Traditional Approach and Object-oriented Approach. [3, 5, 10]V.The object-oriented approach uses to developmentthe object-oriented projects that use the objectoriented programming like: C and nt has a decided advantage over thetraditional approach in dealing with complexity andthe fact that most contemporary languages and toolsare object-oriented.As with any technology or tool invented by humanbeings, all SE methodologies have limitations [9].The software engineering development has two ways todevelop the projects that: traditional approach and objectoriented approach.The traditional approach uses traditional projects thatused in development of their procedural programminglike C, this approach leads software developers to focuson Decomposition of larger algorithms into smaller ones.Was born in Jeddah, Saudi Arabia in 1978. He studiedComputer Science atUniversity of Science andTechnology, Yemen from 1997 to 2001. In 2001 hereceived the Bachelor degree. He studied Master ofInformation Technology at Arab Academic, Yemen, from2004 to 2007. Now he Ph.D. Student 3rd year of CSE atJawaharlal Nehru Technological University (JNTU),Hyderabad, A. P., India. He is working as AssociateProfessor in Computer Science & Engineering College inUniversity Of Science and Technology, Yemen. His areas ofinterest include Software Engineering, System Analysis andDesign, Databases and Object Oriented Technologies.75 P a g ewww.ijacsa.thesai.org
(IJACSA) International Journal of Advanced Computer Science and Applications,Vol. 2, No. 6, 2011Dr.A.GovardhanReceived Ph.D. degree in Computer Science and Engineeringfrom Jawaharlal Nehru Technological University in 2003,M.Tech. from Jawaharlal Nehru University in 1994 and B.E.from Osmania University in 1992. He is working as a Jagitial. He has published around 108 papers in various nationaland international Journals/conferences. His research of interestincludes Databases, Data Warehousing & Mining, InformationRetrieval, Computer Networks, Image Processing, SoftwareEngineering, Search Engines and Object Oriented Technologies.76 P a g ewww.ijacsa.thesai.org
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,
2.1 A comparison of the existing bus ticketing systems 14 2.2 Comparison between Linux, Window and Mac 18 2.3 Comparison between Chrome , Mozilla and IE 20 2.4 Comparison between PHP,ASP.NET and JSP 22 2.5 Comparison between MySQL and Oracle 24 3.1 Data dictionary for AgentBasicInfotable 44 3.2 Data dictionary for feedbacktable 45
Comparison table descriptions 8 Water bill comparison summary (table 3) 10 Wastewater bill comparison summary (table 4) 11 Combined bill comparison summary (table 5) 12 Water bill comparison – Phoenix Metro chart 13 Water bill comparison – Southwest Region chart 14
chart no. title page no. 1 age distribution 55 2 sex distribution 56 3 weight distribution 57 4 comparison of asa 58 5 comparison of mpc 59 6 comparison of trends of heart rate 61 7 comparison of trends of systolic blood pressure 64 8 comparison of trends of diastolic blood pressure 68 9 comparison of trends of mean arterial pressure
Water bill comparison summary (table 3) 10 Wastewater bill comparison summary (table 4) 11 Combined bill comparison summary (table 5) 12 Water bill comparison - Phoenix Metro chart 13 Water bill comparison - Southwest Region chart 14 Water bill comparison - 20 largest US cities chart 15
figure 8.29 sqt comparison map: superior bay (top of sediment, 0-0.5 ft) figure 8.30 sqt comparison map: 21st avenue bay figure 8.31 sqt comparison map: agp slip figure 8.32 sqt comparison map: azcon slip figure 8.33 sqt comparison map: boat landing figure 8.34 sqt comparison map: cargill slip figure
The modern approach is fact based and lays emphasis on the factual study of political phenomenon to arrive at scientific and definite conclusions. The modern approaches include sociological approach, economic approach, psychological approach, quantitative approach, simulation approach, system approach, behavioural approach, Marxian approach etc. 2 Wasby, L Stephen (1972), “Political Science .
Ricoh MP 305 SP Ricoh MP 305 SPF D259 3D Paper Feed Unit PB1090 D794 3D NFC Card Reader Type M13 D3B4 Traditional Optional Counter Interface Unit Type M12 B870 Traditional Bluetooth Interface Unit Type D D566 Traditional XPS Direct Print Option Type M15 D3B4 Traditional SD Card for Fonts Type D D641 Traditional OCR Unit Type M13 D3AC Traditional
Comparison between Smooth and Ring Beam Stiffened Cylindrical Shell Roof Figure 5: Comparison of Analytical method, FEM Method and Zeinkiewicz and Taylor Above figure 5 is the graphical comparison between three solution made for only one problem. This graphical representation gives result for Model 1. First method adopted to solve Scordelis-Lo .
