Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Object Oriented Analysis & Design Software Development Methodologies

Instructor: Tasneem Darwish2 NEW METHODOLOGIES  it is impossible to develop a piece of software in one pass.  Therefore, we need to perform the classical phases of software development several times, adding to and perfecting the system as we go

Instructor: Tasneem Darwish3 Spiral Methodology  We start with requirements capture, which may be relatively complete or rather unclear at this stage;  next, we perform some exploratory analysis to increase our understanding of what it is that we’re dealing with;  then we sketch out a system design that we feel will fit the requirements and design part of the system;  then, despite the fact that all the preceding phases are incomplete, we write some code.  Once we’ve finished our initial coding effort we can try out what we have so far, perhaps by running some informal tests or by showing what we have to our sponsors.

Instructor: Tasneem Darwish4 Spiral Methodology  By the time we’ve been through the cycle once:  we’ve increased our understanding of the problem domain and our understanding of the proposed solution.  We’ve also involved our sponsors, so that they can correct any misunderstanding of the business or the functionality that they expect to see in the final system.

Instructor: Tasneem Darwish5 Spiral Methodology  Once our system is complete, perhaps after three or four spirals, we can perform thorough testing and deploy the system  spiral methodology has fewer problems than the waterfall methodology:  it involves our sponsors throughout the life cycle;

Instructor: Tasneem Darwish6 Spiral Methodology  The spiral methodology isn’t perfect.  The trouble is that we’ve simply attacked the waterfall by doing everything three or four times, which means that, although the problems have got smaller, they haven’t gone away altogether.  We still have some inflexibility, because we’re supposed to proceed in an orderly manner through the classical phases; if we find mistakes, we can’t fix them until the next revolution.  Therefore, the spiral methodology on its own is not much use – we need to combine it with something else.

Instructor: Tasneem Darwish7 Iterative Methodology  Now, we have a much more natural way of massaging our software from its early stages into a well-formed, elegant whole that satisfies all the sponsors.  But, how do we avoid disorder?  We have at least three life-savers here:

Instructor: Tasneem Darwish8 Iterative Methodology  The classical phases remind us what we should be doing at each stage and in which general direction we should be moving.  The artifacts (diagrams, descriptions, code, etc.) that we produce as we work within the classical phases do not get thrown away but are gradually improved as we move towards deployment.  The software production tools that support our chosen methodology and the notations help us to ensure that the artifacts are consistent and kept in one place.

Instructor: Tasneem Darwish9 Iterative Methodology  But we still have a problem.  With the iterative and spiral methodologies we’re still trying to deliver a complete system for deployment.

Instructor: Tasneem Darwish10 Incremental Methodology  our sponsors can see our progress as each piece is delivered;  we get to sign off each piece of work and concentrate on the next;  we can ask for incremental payment.

Instructor: Tasneem Darwish11 Incremental Methodology  we aim to deliver version 1.0 of our system with basic, critical functionality.  Then, some time later, we deliver version 1.1 with additional functionality.  Next, we might deliver version 2.0 with a whole raft of changes. And so on, throughout the lifetime of the system.  we’re keeping up with changing requirements and a shifting marketplace.

Instructor: Tasneem Darwish12 Incremental Methodology  However, we must avoid at all costs the nightmare scenario of rewriting all our code for each new increment – this would be like an endless series of separate waterfalls.  Thus, good analysis, good design, reusable code and extensibility become critical.

Instructor: Tasneem Darwish13 Combining the Methodologies  all methodologies have desirable properties but none of them is good enough on its own.  So, we must combine all four in some way, but how?

Instructor: Tasneem Darwish14 Combining the Methodologies  At the highest level, we know from the incremental methodology that we must plan a succession of increments.  Within each increment, the spiral methodology suggests that we should have at least two attempts to produce each increment.  Within each spiral, the waterfall methodology specifies the phases and the order in which they occur.  Within each mini-waterfall, the iterative methodology allows us to repeat phases, or combinations of phases, as we see fit  the iterative methodology also allows us to fix a problem as soon as we discover it

Instructor: Tasneem Darwish15 OBJECT-ORIENTED METHODOLOGIES  all object-oriented methodologies are alike – they have similar phases and similar artifacts – but there are many small differences.  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 artifact.  The need to model static structure and dynamic behavior.

Instructor: Tasneem Darwish16 OBJECT-ORIENTED METHODOLOGIES  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.  Typically, we produce at least one static model and one dynamic model during each phase of the development

Instructor: Tasneem Darwish17 UML, RUP and XP  By 1996, Jacobson and Rumbaugh had joined Rational Corporation (founded by Booch), and they had developed a set of notations which became known as the Unified Modeling Language (UML)  Once UML was in safe hands, the three amigos set about designing a methodology that drew on the best aspects of their individual work

Instructor: Tasneem Darwish18 UML, RUP and XP  Within a couple of years, they had come up with their own spiral, iterative and incremental method called the Rational Unified Process (RUP) [Jacobson et al. 99].  RUP is not the only methodology available, nor even the only one that uses UML as the notation.

Instructor: Tasneem Darwish19 UML, RUP and XP  Another popular methodology is extreme programming (XP) [Beck 99].  XP is referred to as an agile methodology because it is responsive to change.  XP is distinguished by two ideas: pair programming and test-driven development.  With pair programming, all development is carried out by two people sitting in front of the screen rather than one – the idea is that, rather than improving the speed at which software is produced, pair programming improves the quality of the software  According to fans of test-driven development, continuous testing is so important that not only should it be done by the developers themselves, but the tests should be written before the code.

Instructor: Tasneem Darwish20 The Need for Development Tools  To be effective, any spiral, iterative and incremental methodology requires an end-to-end development tool.  Such a tool should allow members of the project team to produce the artifacts and then to store them. More specifically, it should support:  Traceability: Recording the connections between an artifact and the artifacts derived from it, for example, recording which particular subsystem gave rise to a group of implemented classes. Most traceability information will be entered by developers rather than inferred by the tool.

Instructor: Tasneem Darwish21 The Need for Development Tools  Change history: Recording the changes that were made to artifacts, who made the changes and when. Where feasible (that is, with textual artifacts) the tool should be able to provide a summary of the differences between one edition of the artifact and another.  Multiuser access control: Making sure that simultaneous access to artifacts doesn’t cause problems. There are three mechanisms relevant here: authorization (controlling who can read the artifacts and who can edit them); multiuser read–single-user edit (only allowing one developer at a time to edit an artifact or group of artifacts, but allowing all authorized users to see the unedited version); versioning (allowing any number of developers to edit an artifact, each producing a distinct version of the artifact – at any time, only one version will be the official one).

Instructor: Tasneem Darwish22 The Need for Development Tools  Reduced redundancy: Ensuring that we never have to update anything in more than one place.  Consistency checking: Ensuring that an artifact is consistent with related artifacts  Networked operation: Providing access to all artifacts from any machine on the project network.  Testing the artifacts that we produce, as we go along

Instructor: Tasneem Darwish23 The Need for Development Tools  Rational Corporation developed a tool called Rose, based on RUP and UML. Rose became probably the best-known object-oriented development tool.  In 2003, Rational was bought by IBM and the tool has been reworked as a set of modular products (and is now called Rational Application Developer).  Assignment: write one or two A4 papers about the Rational Application Developer and submit it on Sunday 31/10/2010