swe © solomon seifu 2010 1 lesson 3 fundamentals of oo & uml
TRANSCRIPT
SWE © Solomon Seifu 2010 1
Lesson 3Fundamentals of OO &
UML
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
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
SWE © Solomon Seifu 2010 4
SWE: Principles of OO - Encapsulation
Implementation
Interface
Client
Client
Implementation is hidden from client via the interface
SWE © Solomon Seifu 2010
SWE: Principles of OO - Inheritance or Hierarchy
Person
Student Faculty
Part-time Student Full-time Student Instructor Professor
Is there really an IS-A
relationship or a role play?
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
SWE © Solomon Seifu 2010 7
Fundamentals Of OO Exercise
SWE © Solomon Seifu 2010 8
Fundamentals of OO Exercise Answer
SWE © Solomon Seifu 2010 9
The Unified Modeling Language
(UML)
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
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
SWE © Solomon Seifu 2010 12
SWE: UML - Diagrams
Types Use Case Activity Class Object State Chart Sequence Collaboration Component Deployment Package
CommunicationUse case Activity
ObjectDeployment
State Sequence
ComponentClass
Models
Package
Behavior diagram
Interaction Timing
Interaction diagrams
Are of type behavior diagrams
Structure diagram
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.
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
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
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
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
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
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
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
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?
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.)
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
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...
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
SWE © Solomon Seifu 2010 26
Use Case Diagram
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
SWE © Solomon Seifu 2010 28
SWE: UML - Use Case Diagram (Cont.)
Use Case 1
Use Case 2Actor
System BoundaryInvoking a use case
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
RegularUser
SWE © Solomon Seifu 2010 30
SWE: UML - Use Case Organization
Organize Related Use Cases in PackagesSemantically related
groupsDevelopment groups
etc.
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: IncludeExtend Inherits
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 <<include>>
Base Use Case
Inclusion Use Case
<<include>>
SWE © Solomon Seifu 2010 33
SWE: UML - Use Case (Include Example)
Borrow copy of book
Extend loan
Check for reservation
Book Borrower
<<include>>
<<include>>
SWE © Solomon Seifu 2010 34
SWE: UML - Use Case (Include yet Another Example)
LogIn
CheckOrderStatus
<<include>>
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.
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 <<extend>>
Base Use Case
ExtensionUse Case
<<extend>>
SWE © Solomon Seifu 2010 36
SWE: UML - Use Case (Extend Example)
Take CustomerOrder
Sales Assistant
Sell Customer-Specific
Product
<<extend>>
SWE © Solomon Seifu 2010 37
SWE: UML - Use Case (Extend yet Another Example)
Place OnlineOrder
Specify Shipping Instructions
<<extend>>
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.
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
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 CustomerOrder
Handle Customer Transaction
SalesAssistant
SWE © Solomon Seifu 2010 40
Use Case Diagram Exercise
SWE © Solomon Seifu 2010 41
Use Case Diagram Exercise Answer
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