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

2. Instructor: Tasneem Darwish2 RIPPLE OVERVIEW  For Ripple, UML notation is employed whenever possible.  UML has 13 types of diagram.  The UML specification doesn’t say where these diagrams should be used in any particular methodology – we’re free to use whichever we think is appropriate at any stage:  Use case diagrams categorize the ways in which a system is used.  Class diagrams show classes and how they can be fitted together (they can also show objects).  Object diagrams show only objects and how they can be fitted together.  Activity diagrams show activity by humans or objects in a similar way to a flow chart.  State machine diagrams show the various states of any object with an interesting or complicated life cycle.

3. Instructor: Tasneem Darwish3 RIPPLE OVERVIEW  Communication diagrams show the messages sent between objects in some scenario.  Sequence diagrams show similar information to communication diagrams, but emphasizing sequences rather than connections.  Package diagrams show how related classes are grouped together, for the benefit of developers.  Deployment diagrams show machines, processes and deployed artifacts for a finished system.  Component diagrams show reusable components (objects or subsystems) and their interfaces.  Interaction overview diagrams show individual steps of an activity using sequence diagrams.  Timing diagrams show precise timing constraints for messages and object states.  Composite structure diagrams show how objects fit together in an aggregation or composition, showing interfaces and collaborating objects.

4. Instructor: Tasneem Darwish4 RIPPLE OVERVIEW

5. Instructor: Tasneem Darwish5 RIPPLE OVERVIEW

6. Instructor: Tasneem Darwish6 Use Case Diagram  A use case is a static description of some way in which a system or a business is used, by its customers, its users or by other systems.  A use case diagram shows how system use cases are related to each other and how the users can get at them.  Each bubble on a use case diagram represents a use case and each stick person represents a user

7. Instructor: Tasneem Darwish7 Use Case Diagram  The figure depicts a car rental store accessible over the Internet.  From this picture, we can extract a lot of information quite easily.  For example, an Assistant can make a reservation; a Customer can look for car models; Members can log on; users must be logged on before they can make reservations; and so on.  Each use case is more than just a title such as U7:Make Reservation or U13:Look for Car Models; it must include the actual steps involved in using the system or business.  Although UML specifies a notation for use case diagrams, it doesn’t do so for the steps of the use case itself

8. Instructor: Tasneem Darwish8 Use Case Diagram

9. Instructor: Tasneem Darwish9 Use Case Diagram  RUP refers to the steps of a use case, and a few other bits and pieces, as use case details.  The details for U3:View Car Model Details are shown in the Figure

10. Instructor: Tasneem Darwish10 Class Diagram (Analysis Level)  A class diagram shows which classes exist in the business (during analysis) or in the system itself (during subsystem design).  Figure 5.9 shows an example of an analysis- level class diagram, with each class represented as a labeled box.  Class diagrams (static artifacts) are introduced in Chapter 7.  As well as the classes themselves, a class diagram shows how objects of these classes can be connected together.  For example, Figure 5.9 shows that a CarModel has inside it a CarModelDetails, referred to as its details.

11. Instructor: Tasneem Darwish11 Class Diagram (Analysis Level)

12. Instructor: Tasneem Darwish12 Communication Diagram  A communication diagram, as its name suggests, shows collaborations between objects.  The one shown in Figure 5.10 describes the process of reserving a car model over the Internet:  A Member tells the MemberUI to reserve a CarModel; the MemberUI tells the ReservationHome to create a Reservation for the given CarModel and the current Member; the MemberUI then asks the new Reservation for its number and returns this to the Member.  Communication diagrams (dynamic artifacts) are described in Chapter 7.

13. Instructor: Tasneem Darwish13 Communication Diagram

14. Instructor: Tasneem Darwish14 Deployment Diagram  A deployment diagram (see Figure 5.11) shows how the finished system will be deployed on one or more machines.  A deployment diagram can include all sorts of features such as machines, processes, files and dependencies.  Figure 5.11 shows that any number of HTMLClient nodes (each hosting a WebBrowser) and GUIClient nodes communicate with two server machines, each hosting a WebServer and a CootBusinessServer; each WebServer communicates with a CootBusinessServer; and each CootBusinessServer communicates with a DBMS running on one of two DBServer nodes.  Deployment diagrams (static artifacts) are described in Chapter 8

15. Instructor: Tasneem Darwish15 Deployment Diagram

16. Instructor: Tasneem Darwish16 Class Diagram (Design Level)  The class diagram shown in Figure 5.12 uses the same notation as the one introduced in Figure 5.9.  The only difference is that design-level class diagrams tend to use more of the available notation, because they’re more detailed.  This one expands on part of the analysis class diagram to show methods, constructors and navigability.  Design-level class diagrams (static artifacts) are described in Chapter 10.

17. Instructor: Tasneem Darwish17 Class Diagram (Design Level)

18. Instructor: Tasneem Darwish18 Sequence Diagram  A sequence diagram shows interactions between objects.  Communication diagrams also show interactions between objects, but in a way that emphasizes links rather than sequence.  In this book, sequence diagrams are used during subsystem design, but they’re equally applicable to dynamic modeling during analysis, system design and even requirements capture.  The diagram in Figure 5.13 specifies how a Member can log off from the system.  Messages are shown as arrows flowing between vertical bars that represent objects (each object is named at the top of its bar).  Time flows down the page on a sequence diagram.

19. Instructor: Tasneem Darwish19 Sequence Diagram  Figure 5.13 specifies, in brief:  a Member asks the AuthenticationServlet to logoff;  the AuthenticationServlet passes the request on to the AuthenticationServer, reading the id from the browser session;  the AuthenticationServer finds the corresponding Member object and tells it to set its session id to 0;  the Member passes this request on to its InternetAccount;  finally, the Member is presented with the home page.  Sequence diagrams (dynamic artifacts) are described in detail in Chapter 10.

20. Instructor: Tasneem Darwish20 Sequence Diagram