Unit-1 object oriented systems(OOSD) .ppt
- 2. Software development process consists of Analysis, design, implementation, testing & refinement to transform users’ need into software solution Object-oriented approach requires ◦ more rigorous process to do things right ◦ more time spent on gathering requirements, developing requirements model & analysis model, then turn into design model ◦ need not see code until after 25% development time
- 3. Viewed as a Process to change, refine, transform & add to existing product Within the process, it is possible to replace one sub process with a new one(new sub process should have the same interface as the old process) The process can be divided into small interacting phases-Sub processes. Each sub process should be defined clearly to let it work independently of other sub processes.
- 4. The Software development process can be divided in to sub processes that interact with each other. Each sub process must have the following ◦ A description in terms of how it works ◦ Specification of the input required for the process ◦ Specification of the output to be produced Software development process can be viewed as a series of transformations, where the output of one transformation becomes the input of the subsequent transformation.
- 5. transformation 1(analysis) - translates user’s need into system’s requirements & responsibilities ◦ how they use system can give insight into requirements. ◦ For example, one use of the system might be analyzing an incentive payroll system, which will tell us that this capacity must be included in the system requirements.
- 6. transformation 2 (design) - begins with problem statement, ends with detailed design that can be transformed into operational system Includes ◦ bulk of development activity, ◦ includes definition on how to build software, its development, its testing, design description + prg + testing materials
- 7. transformation 3 (implementation) - refines detailed design into system deployment that will satisfy users’needs ◦ takes account of equipment, procedures, resources, people, etc - how to embed software product within its operational environment, eg: new compensation method prg needs new form, gives new report.
- 9. Starts with deciding “what is to be done?”(what is the problem)- ◦ requirements are gathered “How to accomplish them”(requirements) “Do it”(process requirements) “Test”(if the user’s requirement has been satisfied) “Use”(what we have done)
- 11. When there is uncertainity regarding what’s required or how it can be built Assumes requirements are known before design begins ◦ sometimes needs experience with product before requirements can be fully understood Assumes requirements remain static over development cycle ◦ product delivered meets delivery-time needs
- 12. Assumes sufficient design knowledge to build product ◦ best for well-understood product ◦ Unable to cater software special properties or partially understood issues ◦ doesn’t emphasize or encourage software reuse Problem if environment changes ◦ request changes in programs
- 13. Goal is user satisfaction To achieve high quality software –answer the following questions ◦ How do we determine system is ready for delivery ◦ is it now an operational system that satisfies users’needs? ◦ is it correct and operating as we thought it should ? ◦ Does it pass an evaluation process ?
- 14. 2 basic approaches to system testing-Test according to ◦ how it has been built ◦ what it should do Blum describes a means of system evaluation in terms of four quality measures : correspondence, correctness, verification, and validation. Correspondence measures how well delivered system matches needs of operational environment, as described in original requirements statement
- 15. ◦ validation task of predicting correspondence (true correspondence only determined after system is in place) ◦ correctness measures consistency of product requirements with respect to design specification ◦ verification exercise of determining correctness (correctness objective => always possible to determine if product precisely satisfies requirements of specification)
- 17. Verification ◦ am I building the product right ? ◦ Begin after specification accepted Validation ◦ am I building the right product ? ◦ Subjective - is specification appropriate ? Uncover true users’ needs , therefore establish proper design ? ◦ Begins as soon as project starts Verification & validation independent of each other ◦ even if product follows spec, it may be a wrong product if specification is wrong ◦ eg: report missing, initial design no longer reflect current needs ◦ If specification informal, difficult to separate verification and validation
- 18. Object-oriented software development life cycle consists of ◦ Object-oriented analysis ◦ Object-oriented design ◦ Object-oriented implementation Use-case model can be employed throughout most activities of software development ◦ Following Life cycle model of Jacobson, Ericsson designs traceable across requirements, analysis, design, implementation & testing can be produced ◦ The main advantageall design decisions can be traced back directly to user requirements ◦ usage scenarios can become test scenarios
- 21. Activities Object-oriented analysis - use case driven Object-oriented design Prototyping Component-based development Incremental testing Encourages ◦ viewing of system as a system of cooperative objects ◦ incremental development
- 22. Object oriented analysis phase of software development concerned with ◦ determining system requirements & ◦ identifying classes & their relationship to other classes in the problem domain To understand system requirements ◦ need to identify the users or actors who are the actors ? How do they use system ?
- 23. Use Case, is a name for a scenario to describe the user–computer system interaction. Scenarios can help (in traditional development, it is treated informally, not fully documented) Ivar Jacobson introduced concept of use case scenario to describe user-computer system interaction Scenarios great way of examining ◦ Interaction among objects and their interrelationships
- 24. Typical interaction between user & system that captures users’ goal & needs ◦ In simple usage, capture use case by talking to typical users, discussing various things they might want to do with system ◦ can be used to examine who does what in interactions among objects, what role they play, intersection among objects’ role to achieve given goal is called collaboration ◦ several scenarios (usual & unusual behaviour, exceptions) needed to understand all aspects of collaboration & all potential actions
- 25. Use case modeling : expresses the high level processes & interactions with customers in a scenario & analyzing it . represents the users view of the system or user’s need. gives system uses, system responsibilities developing use case is iterative when use case model better understood & developed, we start to identify classes & create their relationship
- 26. What are physical objects in system ? ◦ Individuals, organizations, machines, units of information, pictures, whatever makes up application/ make sense in context of real world While developing model, objects emerge that help establish workable system Necessary to work iteratively between use- case & object models
- 27. Objects in incentive payroll system - employee, supervisor, office administrator, paycheck, product made, process used to make product Intangible objects ? ◦ Tables, data entry screens, data structures
- 28. Documentation another important activity not to end with OOAto be carried out through out object oriented system development. ◦ 80-20 rule ◦ 80% work can be done with 20% documentation ◦ 20% easily accessible, 80% available to few who needs to know ◦ modeling & documentation inseparable activities ◦ good modeling implies good documentation
- 29. Goal : to design classes identified during analysis phase & user interface This phase we Identify additional objects & classes that support implementation of requirements ◦ Eg. add objects for user interface to system (data entry windows, browse windows) OOA and OOD though different Can be intertwined with analysis phase
- 30. ◦ Highly incremental, we can start with object- oriented analysis, model it, create object-oriented design, then do some more of each again & again, gradually refining & completing models of system ◦ Activities & focus of oo analysis & oo design are intertwined, grown not built
- 31. First, build object model based on objects & relationship Then iterate & refine model ◦ Design & refine classes ◦ Design & refine attributes ◦ Design & refine methods ◦ Design & refine structures ◦ Design & refine associations
- 32. Reuse rather than build new classes ◦ Know existing classes Design large number of simple classes rather than small number of complex classes Design methods Critique what has been proposed ◦ Go back & refine classes
- 33. Prototype – version of software product developed in early stages of product’s life cycle for specific, experimental purposes Enables us to fully understand how easy/difficult it will be to implement some features of system Gives users chance to comment on usability & usefulness of user interface design Can assess fit between software tools selected, functional specification & user needs
- 34. • Can further define use cases, makes use case modeling easier • prototype that satisfies user + documentation define basic courses of action for use cases covered by prototype Important to construct prototype of key system components shortly after products are selected • Picture is worth a thousand words • Prototype is worth a thousand pictures • Build prototype with use-case modeling to design systems that users like & need
- 35. Before: prototype thrown away when industrial strength version developed New trend: (eg. rapid application development) prototype refined into final product ◦ Prototype used as means to test & refine user interface & increase usability of system ◦ As underlying prototype design becomes more consistent with application requirements, more detail can be added to application ◦ Test, evaluate & build further till all components work properly within the prototype framework
- 36. Some of the commonly accepted prototypes Horizontal prototype ◦ Simulation of interface (entire interface in full-featured system) ◦ Contains no functionality ◦ Quick to implement, provide good overall feel of system Vertical prototype ◦ Subset of system features with complete functionality ◦ Few implemented functions can be tested in a greater depth Hybrid prototypes ◦ Major portions of interface established, features having high degree of risk are prototyped with more functionality
- 37. Analysis prototype ◦ Aid in exploring problem domain, used to inform user & demonstrate proof of concept ◦ Not used as basis of development, discarded when it has served purpose. ◦ Final products use the prototype concepts, not code Domain prototype ◦ Aids for incremental development of the ultimate software solution ◦ Often used as a tool for staged delivery of subsystems to users/other members of development team ◦ Demonstrates the feasibility of implementation ◦ Eventually evolves into deliverable product
- 38. Typical time from few days to few weeks Should be done parallel with preparation of functional specification ◦ Can result in modification of specification (some problems/features only obvious after prototype built) Should involve representation from all user groups that will be affected by project ◦ To ascertain all that the general structure of the prototype meets requirements established for overall design
- 39. Purpose of review of the prototypes ◦ To demonstrate that prototype has been developed according to specification & that final specification is appropriate ◦ To Collect info about errors & problems in systems, eg user interface problems ◦ To Give management & everyone connected with project glimpse of what technology can provide Evaluation easier if supporting data readily available Testing considerations must be incorporated in design & implementation of systems
- 40. No more custom development, now assemble from prefabricated components ◦ No more cars, computers, etc custom designed & built for each customer ◦ Can produce large markets, low cost, high quality products ◦ Cost & time reduced by building from pre-built, ready-tested components ◦ Value & differentiation gained by rapid customization to targeted customers
- 41. Industrialized approach to system development, moves form custom development to assembly of pre-built, pre- tested, reusable software components that operate with each other ◦ Application development improved significantly if applications assembled quickly from prefabricated software components ◦ Increasingly large collection of interpretable software components could be made available to developers in both general & specialist catalogs
- 42. Components themselves can be constructed from other components, down to prebuilt components/old-fashioned code written in programming languages like C Visual tools/actual code can be used to glue together components ◦ Visual glue – Digitalk’s Smalltalk PARTS, IBM VisualAge Less development effort, faster, increased flexibility
- 43. Application/component wrapper ◦ surrounds complete system, both code & data ◦ Provides interface to interact with both new & legacy software systems ◦ Off the shelf components not widely available, mostly home-grown within organization Software component ◦ Functional units of programs, building blocks offering collection of reusable services ◦ Can request service form another component or deliver its own services on request
- 44. ◦ Delivery of services of the components independent, components work together to accomplish task ◦ Components can depend on one another without interfering one another ◦ Each component unaware of context/inner workings of other components Aspects of software development ◦ OO concept focuses on analysis, design, programming ◦ Component-based focuses on implementation, system integration
- 45. Component wrapper Component wrapper Component wrapper Component wrapper Legacy screens Legacy programs Legacy data Legacy software packages Subselect and enter title here Open Connectivity
- 46. Set of tools & techniques to build application faster than typically possible with traditional methods Often used in conjunction with software prototyping RAD does not replace the system development life cycle but complements it Focuses more on process specification and can be perfectly combined with the object oriented approach.
- 47. Task of RADto develop application quickly & Iterational development ◦ Incrementally Implement design & user requirements incrementally with tools like Delphi, VisualAge, Visual Basic, or PowerBuilder. ◦ Begins when design gets completed ◦ Main objective to build version of an application to answer Do we actually understood problem (analysis) ? Does the system do what it is supposed to do (design) ? Make improvement in each iteration
- 48. Software development and all of its activities including testing are an iterative process. Waiting until after development wastes money & time Turning over applications to quality assurance group not helps since they are not included in initial plan
- 49. Major benefit of Object-oriented approach For objects to be reusable, much effort must be spent of designing it ◦ Design reusability To deliver a reusable object, the development team must have to design reusability into object. Potential benefits of reuse ◦ Increased reliability ◦ Reduced time & cost of development ◦ improved consistency
- 50. Effectively evaluate existing software components ◦ Has my problem been solved ? ◦ Has my problem been partially solved ? ◦ What has been done before to solve problem similar to this one ? Need ◦ detailed summary info about existing software components ◦ Some kind of search mechanism Define candidate object simply Generate broadly/narrowly defined query
- 51. Information hiding Conformance to naming standards Creation & administration of an object repository Encouragement by strategic management of reuse as opposed to constant redevelopment Establish target for % of object in project to be reuse(i.e., 50 percent of reuse of objects)