1. SWE © Solomon Seifu 2010 1 Lesson 3 Fundamentals of OO & UML

2. SWE © Solomon Seifu 2010 2 SWE: Principles of OO Encapsulation  The implementation is hidden behind an interface, and clients only depend on the interface Inheritance/Hierarchy  Different levels of abstraction that can be used to factor out common functionality Polymorphism  The ability of an object to respond appropriately to the same message based on what kind of an object it is

3. SWE © Solomon Seifu 2010 3 SWE: Principles of OO (Cont.) Open/Closed principle says the code should be closed for modification but open for extension Liskov substitution principle says wherever you use the parent class you can use the child class Programming to the interface means declaring your variables, parameters, and return types to be of the interface type, rather than of any specific implementation type

4. SWE © Solomon Seifu 2010 4 SWE: Principles of OO - Encapsulation Implementation Interface Client Implementation is hidden from client via the interface

5. SWE © Solomon Seifu 2010 SWE: Principles of OO - Inheritance or Hierarchy Person StudentFaculty Part-time StudentFull-time StudentInstructorProfessor Is there really an IS-A relationship or a role play?

6. SWE © Solomon Seifu 2010 6 SWE: Principles of OO - Polymorphism Shape computeArea() Circle computeArea() Square computeArea() Rectangle computeArea() Area = PI * r * r Area = s * s Area = w * l

7. SWE © Solomon Seifu 2010 7 Fundamentals Of OO Exercise

8. SWE © Solomon Seifu 2010 8 Fundamentals of OO Exercise Answer

9. SWE © Solomon Seifu 2010 9 The Unified Modeling Language (UML)

10. SWE © Solomon Seifu 2010 10 SWE: Unified Modeling Language (UML ) Almost all successful software systems are built from models A model is a simple representation of something complex A model makes it possible for those who want to build a system to visualize it It is a way to specify what the system is to do and to guide the construction of the system A model creates a common language, or a common way of understanding

11. SWE © Solomon Seifu 2010 11 SWE: UML (Cont.) The UML provides a set of elements that allow you to model software systems It is a general-purpose modeling language It offers a set of diagrams, views, and modeling elements that help you do the following:  Analyze the requirements you have gathered  Design software using your requirements  Document the software you have developed  Develop test cases  Plan product releases  Discuss and conceptualize software

12. SWE © Solomon Seifu 2010 12 SWE: UML - Diagrams Types Use Case Activity Class Object State Chart Sequence Collaboration Component Deployment Package Communication Use caseActivity ObjectDeployment StateSequence Component Class Models Package Behavior diagram InteractionTiming Interaction diagrams Are of type behavior diagrams Structure diagram

13. SWE © Solomon Seifu 2010 13 Use Cases: A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor.

14. SWE © Solomon Seifu 2010 14 SWE: UML - Use Cases Requirements come in all shapes and forms and from a variety of sources Projects often fail because the requirements were not accurately understood The first thing to do is to make sure the basic requirements are understood This is where use cases come in. You can apply use case modeling to develop a precise model of what is required of the system

15. SWE © Solomon Seifu 2010 15 SWE: UML - Use Cases (Cont.) Ivar Jacobson et.al., popularized the application of use cases for understanding the functional requirements of a system in the early 1990s Use Cases are a widely used technique for requirements specification as part of the Unified Modeling Language (UML) A use case describes things actors want the system to do

16. SWE © Solomon Seifu 2010 16 SWE: UML - Use Cases (Cont.) According to RUP, a Use Case "…fully describes a sequence of actions performed by a system to provide an observable result of value to a person or another system using the product under development." Use cases tell the customer what to expect, the developer what to code, the technical writer what to document, and the tester what to test

17. SWE © Solomon Seifu 2010 17 SWE: UML - Use Cases (Cont.) There are two fundamental concepts in use case modeling:  Actor – An actor represents something (or someone) outside the system, typically a user of the system. Actors interact with the system, which results in some action by the system. Each distinct role is represented by an actor  Use case – A use case encapsulates a sequence of steps performed by the system on behalf of an actor. Use cases provide something of value to the actor. A use case consists of primary sequence of events and may have one or more alternate sequence of events

18. SWE © Solomon Seifu 2010 18 SWE: UML - Use Cases (Cont.) Use cases reside inside the system A use case describes the actions the system takes to deliver to the actor Taken together, all use cases constitute all ways of using the system Is an abstraction of a set of sequences that yield some functionality

19. SWE © Solomon Seifu 2010 19 SWE: UML - Use Cases (Cont.) Represents some user-visible function Is always initiated by an “actor” Describes the interaction between the actors and the system for a system function Achieves a discrete goal for the actor

20. SWE © Solomon Seifu 2010 20 SWE: UML - Purpose of Use Cases To capture functional requirements of a system To communicate with end users and domain experts To design test cases for validating system functionality To provide traceability from requirements into actual classes and operations To drive the development process To plan iterations and releases

21. SWE © Solomon Seifu 2010 21 SWE: UML - Use Cases (Identifying the Actors) As you read the description or gather requirements for a project, ask yourself a few important questions:  Who will use this functionality?  Who is supplying or obtaining information?  Who can change the information?  Are there any other systems that interact with the system being developed?

22. SWE © Solomon Seifu 2010 22 SWE: UML - Use Cases (Identifying the Actors) (Cont.) An actor can be a person; but it may also be another system, or perhaps a device such as a printer An actor may even be a signal or event to which you must respond. From a component design perspective, you might model the clients of your component as actors, even though those are “the system” from the perspective of the designers of those components. (And conversely, of course, your component is an actor from their perspectives.)

23. SWE © Solomon Seifu 2010 23 SWE: UML - Use Cases (Identifying the Actors) (Cont.) Who uses the main functionality of the system? Which hardware devices the system needs to handle? Which other systems does the system need to interact with? What nouns/subjects are used to describe the system? For example:  The Reservation Clerk makes a booking using the system, based on the...  A user must login in order to save his itinerary

24. SWE © Solomon Seifu 2010 24 SWE: UML - Use Cases (Finding Use Cases) What functions does the system perform? What functions do the “actors” require? What input/output does the system need? What verbs are used to describe the system? For example:  The Reservation Clerk makes a booking using the system, based on the...  The Airport Manager can make an entry for a new flight. He can also modify flight details, provided...

25. SWE © Solomon Seifu 2010 25 SWE: UML - Use Cases (Finding Use Cases) (Cont.) Use cases are always expressed from the perspective of the actor (that is, the user of the system) The idea is to capture the sequence of events performed by the system at the requests of the actor, such that they yield some observable, valuable results to the actors

26. SWE © Solomon Seifu 2010 26 Use Case Diagram

27. SWE © Solomon Seifu 2010 27 SWE: UML - Use Case Diagram In the UML, actors are represented by a stick figure, and use cases are shown as ellipses A use case diagram simply shows the structural relationships between the actors and the use cases, not the dynamic relationships The relationship between actors and use cases is shown via a non-directional association even though indicating source of invocation is always the actor

28. SWE © Solomon Seifu 2010 28 SWE: UML - Use Case Diagram (Cont.) Use Case 1 Use Case 2 Actor System Boundary Invoking a use case

29. SWE © Solomon Seifu 2010 29 SWE: UML - Use Case Diagram (Inheritance Between Actors) An actor in a use case diagram can inherit another actor The standard UML notation for inheritance, the open- headed arrow, is used and the advice presented about the appropriate use of inheritance still applies:  it should make sense to say the inheriting actor is or is like the inherited actor User Super User Regular User

30. SWE © Solomon Seifu 2010 30 SWE: UML - Use Case Organization Organize Related Use Cases in Packages  Semantically related groups  Development groups etc.

31. SWE © Solomon Seifu 2010 31 SWE: UML - Use Case Relationship The UML notation provides the following relationships, which can be used to model reuse within use cases They are:  Include  Extend  Inherits

32. SWE © Solomon Seifu 2010 32 SWE: UML - Use Case (Include or Uses) An include relationship allows you to capture a common piece of functionality in a separate use case, and then “include” the use case in another use case via the include relationship The include relationship is shown as a dependency relationship stereotyped as > Base Use Case Inclusion Use Case >

33. SWE © Solomon Seifu 2010 33 SWE: UML - Use Case (Include Example) Borrow copy of book Extend loan Check for reservation Book Borrower >

34. SWE © Solomon Seifu 2010 34 SWE: UML - Use Case (Include yet Another Example) LogIn CheckOrderStatus > The following figure illustrates an e- commerce application that provides customers with the option of checking the status of their orders. This behavior is modeled with a base use case called CheckOrderStatus that has an inclusion use case called LogIn. The LogIn use case is a separate inclusion use case because it contains behaviors that several other use cases in the system use. An include relationship points from the CheckOrderStatus use case to the LogIn use case to indicate that the CheckOrderStatus use case always includes the behaviors in the LogIn use case.

35. SWE © Solomon Seifu 2010 35 SWE: UML - Use Case (Extend) An extend relationship allows you to model optional behavior for a use case. That is, you can capture some behavior in a separate use case and, within another use case, indicate the exact points (called extension points) where the separate use case may optionally be invoked as part of the use case An extend relationship is modeled as a dependency and stereotyped as > Base Use Case Extension Use Case >

36. SWE © Solomon Seifu 2010 36 SWE: UML - Use Case (Extend Example) Take Customer Order Sales Assistant Sell Customer-Specific Product >

37. SWE © Solomon Seifu 2010 37 SWE: UML - Use Case (Extend yet Another Example) Place Online Order Specify Shipping Instructions > You are developing an e-commerce system in which you have a base use case called Place Online Order that has an extending use case called Specify Shipping Instructions. An extend relationship points from the Specify Shipping Instructions use case to the Place Online Order use case to indicate that the behaviors in the Specify Shipping Instructions use case are optional and only occur in certain circumstances.

38. SWE © Solomon Seifu 2010 38 SWE: UML - Inheritance Between Use Cases Use cases can inherit from other use cases A generalization/specialization relationship exists The inheriting use case would completely replace one or more of the courses of action of the inherited use case

39. SWE © Solomon Seifu 2010 39 SWE: UML - Use Case (Generalization Example) In the example shown, we would be indicating that there are some common steps for all Use Cases that handle customer transactions and that the child Use Cases “Return Faulty Goods” and “Take Customer Order” have additional steps that fit into or around them Return Faulty Goods Take Customer Order Handle Customer Transaction Sales Assistant

40. SWE © Solomon Seifu 2010 40 Use Case Diagram Exercise

41. SWE © Solomon Seifu 2010 41 Use Case Diagram Exercise Answer

42. SWE © Solomon Seifu 2010 SWE: Fundamentals of OO & UML - Wholeness Encapsulation, Inheritance and Polymorphism are the three corner stones of OOP The saying “A picture speaks a thousand words” implies that images, figures & models are powerful concepts that enable the conveyance of a complex idea. UML does just that Use Case modeling is widely used to capture and articulate requirements specifications