×
Every great story on the planet happened when someone decided not to give up, but kept going no matter what.
--Your friends at LectureNotes
Close

Note for Object Oriented Software Engineering - OOSE by Krishna Mohan

  • Object Oriented Software Engineering - OOSE
  • Note
  • Krishna University - KUMTM
  • 155 Views
  • 3 Offline Downloads
  • Uploaded 3 months ago
Krishna Mohan
Krishna Mohan
0 User(s)
Download PDFOrder Printed Copy

Share it with your friends

Leave your Comments

Text from page-1

UNIT 2 : SOFTWARE PROCESS Unified Process • • • • • • • process encompasses paradigms and methodologies, life cycle models, tools, techniques, personnel Unified Process is name of predominant object-oriented methodology unification of several separately developed OO methodologies recall "three amigos": Grady Booch, Jim Rumbaugh, Ivar Jacobson (see http://c2.com/cgi/wiki?ThreeAmigos) Unified Modeling Language (UML) is Unified Process centerpiece full Unified Process is large and complex so it can be used for developing large and complex systems has five core workflows: requirements, analysis, design, implementation, test Requirements workflow • • • • • • • • goal: determine client needs begin by identifying client constraints, or risks: o technology constraints, such as quality (reliability, robustness) or environmental (size, response time) attributes o budget constraints, which vary with client-developer relationship (fixed, developer bid) o schedule constraints, with deadline fixed by client for a good reason developer needs to be or become familiar with application (client's) domain solution (developer's) domain is not relevant yet client does not always know what he/she needs client perceived needs may not match actual needs feasibility should be determined here results are documented in natural language Analysis workflow • • • • goal: produce set of specifications acceptable to both client and developer goal: produce project management plan object-oriented analysis (OOA) involves discovering classes in client's world, their attributes, behaviors and relationships specifications are a contract between client and developer o document must focus on what the system should do, not how it will be done o document contents must be unambiguous so natural language is poor choice, use diagrams o document must be readable and understandable to both client and developer

Text from page-2

statements must be precise (e.g. "system will respond within 1 second, 95% of the time") o document must cover both functional (e.g. features) and nonfunctional (e.g. size, response time) requirements o document must be detailed, so a design can be developed from it and implementation based on the design o document should be complete, covering all aspects of the application both client and developer sign off on specification document if client and developer are from different organizations, contract law applies to specification document properly drawn specifications become source for acceptance tests specifications are used by developer for project planning and time/cost estimates project plan includes information such as o development objectives o the software process and life cycle to be used o design, implementation, testing and maintenance tools and practices to be used o organizational structure of the development team o completion milestones, so progress can be measured o detailed workflow schedules o detailed budgets where do verification and validation come into play? o • • • • • • Design workflow • • • • • • • • • goal: produce design that accurately reflects specifications and upon which implementation can be based designer translates client's world (specifications document) to developer's world (design documents) programmers use design documents as implementation guidelines tools and techniques depend on approach, with basic commonalities o classical approach is define architecture then decompose into subsystems, then decompose subsystems into modules top-down; and design data structures o object-oriented design (OOD) approach is identify and design classes, attributes, behaviors, relationships OO class is counterpart to classical module OOD classes are not necessarily same as OOA classes (its a "win" when they are) design should be done with maintenance in mind (hooks to facilitate perfective maintenance) design details need to be traceable back to specifications -- more on this later where do verification and validation come into play?

Text from page-3

Implementation workflow • • • • • • • goal: produce software that correctly implements the design implementors base their programs on the provided design implementation tasks are assigned to programmers according to methodology in classical view, subsystems are assigned to teams and their modules to individuals in OO view, classes are assigned to individuals/pairs integration must occur frequently - pull pieces together to make the whole where do verification and validation come into play? Test workflow • • • • • • • • • goal: ensure that the artifacts (products of work) in the other workflows are correct the test workflow happens in conjunction and in parallel with the other workflows developer should have software quality assurance (SQA) team for this much testing is done in review sessions, with client involvement at analysis workflow traceability is crucial o elements of specification (analysis) must be traceable back to corresonding elements of requirement o elements of design must be traceable back to corresonding elements of specification o elements of implementation must be traceable back to corresonding elements of design o tracing is facilitated by consistent numbering and cross-referencing across workflow documents common faults in all workflows are caught o mismatch in details of corresponding elements from different workflows (verification) o interface faults, such as parameter matches o logic faults o omissions much testing is done manually, such as tracing and verification of design details some same, some different testing tools and techniques apply in different workflows important tests associated with implementation include o unit testing - testing individual methods/classes in isolation o code reviews - programmers and SQA folks go over code line-by-line manually o integration testing - pull classes/modules together and test the whole

Text from page-4

product testing - developer testing of implementation against specifications o acceptance testing - client runs tests in real environment with real data o alpha and beta testing - usually for COTS (commercial off-the-shelf), released to willing potential clients after product testing important test in maintenance is regression testing - after change is made, re-run all previous tests to assure the change didn't break something that previously worked! where do verification and validation come into play? o • • Unified Process Phases • • • • • • Two implementations of the Unified Process are o Rational Unified Process (RUP). see http://www306.ibm.com/software/rational/ o Enterprise Unified Process (EUP). see http://www.enterpriseunifiedprocess.info/ Unified Process consists of phases as well as workflows The phases are sequential, the workflows parallel - all are present in each phase There are four development phases, nicely introduced at http://ootips.org/rup.html (questions courtesy of Dan Rawsthorne) o inception phase: do you and the Customer have a shared understanding of the system? o elaboration phase: do you have an architecture to be able to build the system? o construction phase: are you developing product? o transition phase: are you trying to get the Customer to take ownership of the system? There are also two post-deliver phases o production phase o retirement phase Inception Phase details o goal is determine if the project is economically viable for all concerned o emphasis on requirements workflow: ▪ understand client domain and build business model ▪ identify and prioritize as many risks as possible ▪ mitigate risks starting with the most critical o some phase deliverables include ▪ initial domain and business models ▪ initial requirements documents ▪ preliminary analysis documents ▪ preliminary system architecture

Lecture Notes