Chapter 1. OO Programming A programming language that supports the concepts of encapsulation, inheritance and polymorphism.

Transcription

1 [Applying UML and Patterns Summary f ch.1-5] [ Adv. Sftware Eng.] By: Salha Alzahrani -University f Technlgy Malaysia Chapter 1 Patterns Principles and guidelines OOA/D Tpics and Skills Iterative develpment with an agile Unified Prcess UML ntatin Requirements analysis Imprtant learning gal A critical ability in OO develpment is t skillfully assign respnsibilities t sftware bject. OO Analysis there is an emphasis in finding and describing the bjects r cncepts in the prblem dmain. e.g. Flight IS has cncepts such as plane, flight and pilt. OO Design r simply bject design there is an emphasis n defining sftware bjects and hw they cllabrate t fulfill the requirements. e.g. Plane sftware bject may have tailn att. And getflighthistry methd. During implementatin r bject riented prgramming, design bjects are implemented, such as Plane class in Java. OOA/D Object riented Analysis and Design fr creatin f well-designed, rbust, maintainable sftware using OO technlgies and languages such as Java r C#. OO Prgramming A prgramming language that supprts the cncepts f encapsulatin, inheritance and plymrphism. Assign respnsibilities t sftware bject. Why? Strngly influences the rbustness, maintainability and reusability f sftware cmpnents. GRASP emphasize principles f respnsibility assignment. Such as -> Infrmatin Expert and Creatr Pattern a named descriptin f a prblem, slutin, when t apply the slutin, and hw t apply the slutin in new cntext. Basic SW Prcess Analysis emphasizes an investigatin f the prblem and requirements rather than a slutin. It emphasizes the questin what rather than hw. Analysis is abrad term. In requirements analysis, it means an investigatin f the requirements. In bject riented analysis it means an investigatin f the dmain bjects. Design emphasizes a cnceptual slutin (in hardware r sftware) that fulfills the requirements rather than its implementatin. It emphasizes the questin hw the system will wrk. Ultimately, designs can be implemented, and the implementatin (hardware r sftware) expresses cmplete and true realized design. e.g. a descriptin f a database schema and sftware bject. Analysis D the right things Design D the things right OO a paradigm that uses bjects and their interactins t design a system. UML the Unified Mdeling Language is a visual language fr specifying, cnstructing and dcumenting the artifacts f systems. [1] UML is just diagramming ntatin [2] UML is nt OOA/D r a methd [3] UML is de fact standard diagramming ntatin fr drawing r presenting pictures (primarily OO sftware)

2 [Applying UML and Patterns Summary f ch.1-5] [ Adv. Sftware Eng.] By: Salha Alzahrani -University f Technlgy Malaysia UML define varius UML prfiles that specialize subset f the ntatin fr cmmn subject areas. Mdel Driven Architecture (MDA) underlying the UML ntatin is the UML meta-mdel that describes the semantics f the mdeling elements. 3 ways t use UML Sketch Infrmal and incmplete diagrams Cnceptual Perspective Blueprint Very quick, requires n fancy tls Preferred by Agile mdelers Often gd enugh t explre difficult parts f the prblem r slutin space, expliting the pwer f visual languages. Detailed mdel drawn by tl Used either fr reverse engineering t visualize and better understanding existing cde in UML diagrams Or fr cde generatin Executable prgramming language Prepare cmplete suite f mdels fr system Cmpile mdels autmatically int executable cde but nrmally seen r mdified by develpers (Nt ready fr primetime ) Eliminates cstly cding activity 3 perspectives t apply UML Diagrams are interpreted as describing things in a situatin f the real wrld r dmain f interest. Specificatin (SW) Perspective Diagrams, using the same ntatin as in the cnceptual perspective, describe sw abstractins r cmpnents with specificatins and interfaces, but n cmmitment t a particular implementatin such as Java r C#. Implementatin (SW) Perspective Diagrams describe sw implementatins in a particular technlgy such as Java. The meaning f class in different perspectives Dmain Cncept r Cnceptual Class real-wrld cncept r thing. A cnceptual r essential perspective. The UP dmain mdel cntains cnceptual classes. Sftware Class a class representing a specificatin r implementatin perspective f a sw cmpnent, regardless f the prcess r methd. UML class diagram cntains sw classes. Implementatin Class a class implemented in a specific OO language such as Java. UML class diagram cntains implementatin classes. Chapter 2 SW develpment prcess describes an apprach t building, deplying and pssibly maintaining sftware.

3 [Applying UML and Patterns Summary f ch.1-5] [ Adv. Sftware Eng.] By: Salha Alzahrani -University f Technlgy Malaysia Iterative develpment cntrasted with a sequential r waterfall lifecycle invlves early prgramming and testing f a partial system in repeating cycles. It als nrmally assumes develpment starts befre all the requirements are defined in detail; feedback is used t clarify and imprve the evlving specificatins. In this lifecycle UP apprach, develpment is rganized int a series f shrt, fixed-length mini-prjects called iteratins. The utcme f each iteratin is a tested, integrated and executable partial system. Each iteratin include its wn requirements analysis, design, implementatin and testing activities. Als called: (1) Iterative and evlutinary develpment because feedback and adaptatin evlve the specificatin and design after each iteratin. (2) Iterative and incremental develpment because f successive enlargement and refinement f a system thrugh multiple iteratins. Iteratins shuld be timebxed, r fixed in length. Partial system must be integrated, tested and stabilized by the scheduled date. Extending the date is illegal. Waterfall Lifecycle r sequential lifecycle prcess attempts t define in detail all r mst f the requirements befre prgramming. And ften, t create a thrugh design r set f mdels befre prgramming. It prmted big upfrnt speculative requirements and design steps befre prgramming. It emerges highest failure rates due t belief r hearsay rather than statistically significant evidence f the defined requirements, analysis and designs. Why is the waterfall s Failure-Prne? This is strngly related t a key false assumptin that the specificatins are predictable and stable, and can be crrectly defined at the start f the prject with lw change rates. Key benefits f iterative prcess 1. Higher prject success rate [1] Better management f cmplexity [2] Early mitigatin f high risks (technical, requirements, bjectives, usability..etc) [3] Easier adaptatin t changing reqs. 2. Higher prductivity & lwer defect rate 3. Client visibility int prject status.. early feedback, user engagement and adaptatin. 4. Early lessns learned applied t later iteratins Hw lng an iteratin be? Iteratin Timebxing.. Recmmended length between 2 and 6 weeks. Small steps, rapid feedback and adaptatin are central ideas in iterative develpment. Lng iteratins subvert the cre mtivatin fr iterative develpment and increase risks. Hwever, sw develpment is n average a dmain f high change and instability knwn as the dmain f new prduct develpment. On the ther hand, iterative and evlutinary methds assume and embrace change and adaptatin f partial and evlving specificatins, mdels and plans based n feedback. The need fr feedback and adaptatin In cmplex, changing systems (such as mst sw prjects) feedback and adaptatin are key ingredients fr success. [1] Feedback frm (i) early develpment, (ii) prgrammers trying t read specificatins and (iii) client dems t refine the requirements

4 [Applying UML and Patterns Summary f ch.1-5] [ Adv. Sftware Eng.] By: Salha Alzahrani -University f Technlgy Malaysia [2] Feedback frm (i) test and (ii) develpers t refine the design r mdels [3] Feedback frm the (i) prgress f the team tackling early features t refine the schedule and estimates [4] Feedback frm the (i) client and (ii) marketplace t repriritize the features t tackle in the next iteratin Risk-Driven & Client-Driven Iterative Planning The UP encurage a cmbinatin f them. S, the gal f the early iteratins are chsen t (1) identify and drive dwn the highest risks, and (2) build visible features that the client cares mst abut. Architecture-centric iterative develpment the early iteratins in risk-driven iterative develpment fcus n building, testing and stabilizing the cre architecture.. Why? Because nt having a slid architecture is a cmmn high risk. Agile (flexible, light) apprach t the well-knwn Unified Prcess(UP) is used as the sample iterative develpment prcess. Fr analysis and design, agile UP validate their applicability t thers methds, Scrum, Feature Driven Develpment, Lean Develpment, Crystal Methd and s n. [5] Dn t mdel alne. Mdel in pairs (r triads) at the whitebard, in the awareness that the purpse f mdeling is t discver, understand and share that understanding. [6] Create mdels in parallel. [7] Use gd enugh simple ntatin. Exact UML details are nt imprtant. [8] Knw that all mdels are inaccurate and the final design will be different. Agile develpment apply timebxed iterative and evlutinary develpment, emply adaptive planning, prmte incremental delivery, and include ther values and practices that encurage agility rapid and flexible respnd t change. Agile methds n specific definitin fr specific practices. Hwever, shrt, timebxed iteratins with evlutinary refinement f plans, requirements and designs is the best practice the methds share. In additin, they prmte practices and principles that reflect an agile sensibility f simplicity, lightness, cmmunicatin, self-rganizing teams and mre. Agile mdeling emphasizes UML as a sketch; this is a cmmn way t apply UML, ften with a high return n the investment f time. The purpse f mdeling is primarily t understand nt t dcument. It implies a number f practices and values including: [1] Adpting and agile methd des nt mean aviding any mdeling. Many agile methds such as feature-driven develpment, DSDM and Scrum nrmally include significant mdeling sessins. [2] The purpse f mdeling is t supprt understanding and cmmunicatin, nt dcumentatin. [3] Dn t mdel r apply UML t all r mst f the sw design. Defer simple r straightfrward design prblems until prgramming. Slve them during prgramming and testing. Agile manifest Individuals and interactins Wrking SW Custmer cllabratin Respnding t change Agile Principles ver prcesses and tls ver cmprehensive dcumentatin ver cntract negtiatin ver fllwing a plan [1] The highest pririty is t satisfy the custmer reqs. [2] Welcme changing reqs even in late develpment. [3] Deliver wrking sw frequently with a preference t the shrter time scale. [4] Business peple and develpers must wrk tgether daily thrughut the prject. [5] Build prjects arund mtivated individuals. [4] Use the simplest tl pssible.

5 [Applying UML and Patterns Summary f ch.1-5] [ Adv. Sftware Eng.] By: Salha Alzahrani -University f Technlgy Malaysia [6] The mst efficient and effective methd f cnveying inf. t and within a develpment team is face-2-face cnversatin. [7] Wrking sw is the primary measure f prgress. [8] Agile prcesses prmte sustainable develpment. [9] Spnsrs, develpers and users shuld be able t maintain a cnstant pace indefinitely. [10]Cntinuus attentin t technical excellence and gd design enhance agility. [11]Simplicity is essential. [12]Best architectures, requirements and designs emerge frm self-rganizing teams. [13]At regular intervals, the team reflects n hw t becme mre effective, then tunes and adjusts its behaviur accrdingly. UP Unified Prcess has emerged as a ppular a ppular iterative sw develpment prcess fr building OO systems. - is very flexible and pen, - encurages including skilful practices frm ther iterative methds., - such as frm Extreme Prgramming (XP) & Scrum - UP cmbines cmmnly accepted best practices, such as iterative life cycle and risk driven develpment, int a chesive and well-dcumented prcess descriptin. RUP Ratinal Unified Prcess a detailed refinement f the UP that has been widely adpted. Agile UP The UP was nt meant by its creatrs t be heavy r un-agile. Rather, it was meant t be adpted and applied in the spirit f adaptability and lightness. Examples f hw this applies: Fcus f this bk Sample UP Disciplines [1] Prefer a small set f UP activities and artifacts and in general keep it simple. Remember that all UP artifacts are ptinal, and avid creating them unless they add value. Fcus n early prgramming nt early dcumenting. [2] Since the UP is iterative and evlutinary, requirements and designs are nt cmpleted befre implementatin. Business Mdeling Requirements They adaptively emerge thrugh a series f iteratins based n feedback. [3] Apply UML with agile mdeling practices. [4] There isn t a detailed plan fr the entire prject. Detailed plan is dne adaptively frm iteratin t iteratin. Imprtant UP practices [1] Tackle high-risk and high-value in early iteratins. [2] Cntinuusly engage users fr evaluatin, feedback and requirements. [3] Build cre architecture in early iteratins. [4] Verify quality by testing thrughut. [5] Fcus n essential mdels using UML [6] Manage reqs. with use cases [7] Practice change request & cnfiguratin management. UP phases A UP prject rganizes the wrk and iteratins acrss 4 majr phases: [1] Inceptin: apprximate visin, business case, scpe, vague estimates. [2] Elabratin: refined visin, iterative implementatin f the cre architecture, reslutin f high risks, identificatin f mst requirements and scpe, mre realistic estimates. [3] Cnstructin: iterative implementatin f the remaining lwer risk and easier elements and preparatin fr deplyment. [4] Transitin: beta tests, deplyment Design Implementatin Test Deplyment Cnfiguratin & Change Management Prject Management Envirnment A fur-week iteratin (fr example). A mini-prject that includes wrk in mst disciplines, ending in a stable executable. Ntes: Iteratins This is nt the ld waterfall r sequential lifecycle f first defining all requirements, and then ding mst r all f the design. Inceptin is nt a requirements phase; it is a feasibility phase, where just enugh investigatin is dne t supprt a decisin t cntinue r stp. Nte that althugh an iteratin includes wrk in mst disciplines, the relative effrt and emphasis change ver time. This example is suggestive, nt literal.

6 [Applying UML and Patterns Summary f ch.1-5] [ Adv. Sftware Eng.] By: Salha Alzahrani -University f Technlgy Malaysia Similarly, elabratin, is nt the requirements r design phase; it is a phase where the cre architecture is iteratively implemented, and high-risk issues are mitigated. Discipline a set f activities and related artifacts in ne subject area, such as the activities within requirements analysis. Artifact in UP, is the general term fr any wrk prduct: cde, web graphics, database schema, text dcs, diagrams, mdels, and s n. UP disciplines UP describes wrk activities within disciplines. Sme UP disciplines include: [2] Feasible? [3] Buy and/r Build? [4] Rugh unreliable range f cst? [5] Shuld we prceed r stp? The purpse f the inceptin phase is nt t define all the requirements, r t generate believable estimate r prject plan. Mst f the requirements analysis ccurs during the elabratin phase. Inceptin in 1 sentence: Envisin the prduct scpe, visin and business case [1] Business Mdeling: The Dmain Mdel artifact t visualize ntewrthy cncepts in the applicatin dmain. [2] Requirements: The Use-Case Mdel and Supplementary Specificatin artifacts t capture functinal and nnfunctinal requirements. [3] Design: The Design Mdel artifact t design the sftware bjects. Mre! A. Implementatin discipline in UP means prgramming building the system nt deplying it. B. Envirnment discipline means establishing the tls and custmizing the prcess fr the prject. i.e. setting up the tl and prcess envirnment. Chapter 4 Inceptin An initial step with the fllwing types f questins are explred: [1] What is the visin and business case fr this prject? The main prblem slved in 1 statement: D the stakehlders have basic agreement n the visin f the prject, and is it wrth investing in serius investigatin? Inceptin Artifacts a ppular iterative sw develpment prcess fr building OO systems. Artifact Visin and Business Case Use-Case Mdel Supplementary Specificatin Glssary Risk list & Risk Management Plan Prttypes and prf-fcncepts Iteratin Plan Phase Plan & Sftware Develpment Cmment Describes the high-level gals and cnstraints, the business case, and prvides an executive summary. Describes the functinal requirements. During inceptin, the names f mst use cases will be identified, and perhaps 10% f the use cases will be analyzed in detail. Describes ther requirement, mstly nn-functinal. During inceptin, it is useful t have sme idea f the key nnfunctinal requirement that have will have a majr impact n the architecture. Key dmain terminlgy, and data dictinary. Describes the risks (business, technical, resurce, schedules) and ideas fr their mitigatin r respnse. T clarify the visin, and validate technical ideas. Describes what t d in the first elabratin iteratin. Lw-precisin guess fr elabratin phase duratin and effrt. Tls, peple, educatin, and ther resurces.

7 [Applying UML and Patterns Summary f ch.1-5] [ Adv. Sftware Eng.] By: Salha Alzahrani -University f Technlgy Malaysia Plan Develpment Case Chapter 5 A descriptin f the custmized UP steps and artifacts fr this prject. In the UP, ne always custmizes it fr the prject. Requirements capabilities and cnditins t which the system, and mre bradly the prject, must cnfrm. The UP prmtes a set f best practices and ne f them is manage reqs. This des nt mean the waterfall attitude f fully define and stabilize the requirements in the first stage f the prject befre prgramming, but rather in UP best practice is a systematic apprach t finding, dcumenting, rganizing and tracking the changing reqs f a system. Challenges! 1. Discver 2. Verify 3. Dcument 4. Priritize 5. Business value 6. Technical difficulty 7. Revise/update/delete 8. Ensure they re implemented crrectly (traceability) Deferred/rejected requirements Just as imprtant as accepted reqs. We need t dcument why reqs. deferred/rejected. Otherwise, yu ll revisit the same issues. But It is likely t be neglected in many agile prjects. Interesting stats n reqs gathered in waterfall prjects 25% f reqs change during prject 65% f reqs never/rarely used!. [4] Supprtability Maintainability, cnfigurability, custmizability & internatinalizatin. The + in FURPS indicates sub-factrs such as: [5] Implementatin Languages, tls, hardware [6] Interface Interfaces with 3rd party (external) systems [7] Operatins System management & its perating envirnment [8] Packaging Physical frm factr [9] Legal Licensing & regulatry. Dcumenting Reqs Hw are reqs rganized in UP artifacts? Functinal reqs g in Use Case Mdel URPS+ usually g in Supplementary Specificatin Glssary may cntain validatin rules Visin may cntain high-level reqs Business Rules Dmain expertise incrprated in system Arguably mst valuable cmpany asset Usually crss applicatin bundaries Shuld be in separate artifact Types/Categries f Requirements FURPS+ A. Functinal (behaviur): ability t perfrm user s task features, capabilities, & security B. Nn-functinal (URPS+) /quality attributes/quality requirements (anything else) [1] Usability Human factrs, help, dcumentatin [2] Reliability Failure rate, recverability [3] Perfrmance Respnsiveness (respnse time), thrughput, accuracy, availability, & resurce usage.