Software Engineering : OOAD using UML

1. Software Engineering Principles
Ajit K Nayak, Ph.D.
ajitnayak@soauniversity.ac.in
Object oriented Software design
using UML

2. Acknowledgements
• Slides of Prof. Rajib Mall, IIT, KGP

3. Introduction
• Object-oriented (OO) design techniques are extremely
popular:
– Inception in early 1980’s and nearing maturity.
– Widespread acceptance in industry and
academics.
– Unified Modelling Language (UML) already an ISO
standard (ISO/IEC 19501).

4. Object Oriented
• A system is designed as a set of interacting objects:
– Often, real-world entities: e.g. an employee, a book
etc.
– Can be conceptual objects also: e.g. Controller,
manager, etc.
• Objects consists of data (attributes) and functions
(methods) that operate on data.
– Encapsulation
• Hides organization of internal information
– Data abstraction

5. Model of an Object
Data
Class
m8 m7
m6
m5
m4m3
m2
m1
mi are methods
of the class

6. Components of Object Model
• Class
• Methods & Messages
• Relations
– Inheritance
– Association
– Aggregation/composition
– Dependency
• Polymorphism
• Genericity

7. Advantages of Object-Oriented
Development
• Code and design reuse
• Increased productivity
• Ease of testing and maintenance
• Better understandability
• Elegant design:
– Loosely coupled, highly cohesive objects:
– Essential for solving large problems.
• Initially incurs higher costs
– After completion of some projects reduction in cost
become possible
• Using well-established OO methodology and environment:
– Projects can be managed with 20% -- 50% of traditional
cost of development.

8. Object modelling using UML
• Unified Modeling Language is a modelling language
– Not a system design or development methodology
• Used to document object-oriented analysis and design
• Independent of any specific design methodology
• UML developed in early 1990s
– To standardize the large number of object-oriented
modelling notations that existed.
• Current version is UML2.0
• Adopted by Object Management Group (OMG) in 1997
– OMG an association of industries that promotes
consensus notations and techniques

9. Object Modelling Techniques
UML
Booch’s
Methodology
[Booch 1991]
OOSE
[Jacobson 1992]
OMT [Rumbaugh 1991]

10. Flash Back
• Grady Booch was
working as Chief
Scientist of Rational
Software Corporation
• Rational Software
Corporation hired James
Rumbaugh from General
Electric in 1994
• Ivar Jacobson joined
them at Rational in 1995
• And the History is made
Booch
Rumbaugh
Jacobson

11. When you want to build a house!

12. What is UML
• UML a graphical modelling tool, easy to understand
and construct
• It provides many diagrams to capture different views
of a system
– Model is required to capture only important aspects
– Helps in managing complexity

13. UML 1.x Diagrams
• 9 diagrams supporting 5 views
User’s View
-Use Case
Diagram
Structural View
- Class Diagram
- Object Diagram
Implementation View
- Component Diagram
Environmental View
- Deployment Diagram
Behavioural View
- Sequence Diagram
- Collaboration Diagram
- State-chart Diagram
- Activity Diagram

14. UML 2.0 Diagrams
UML 2.0
Diagram
Behavior
Diagram
Structure
Diagram
Class
Diagram
Composite
Structure Diagram
Object
Diagram
Activity
Diagram
Use Case
Diagram
State Machine
Diagram
Interaction
Diagram
Component
Diagram
Deployment
Diagram
Package
Diagram
Sequence
Diagram
Communication
Diagram
Interaction
Overview
Diagram
Timing
Diagram

15. Use Case Modelling

16. Use Case Model
• Consists of a set of “use cases”
• It is the central model:
– Other models must conform to this model
– Not really an object-oriented model
– A functional model of the system
• Use Cases are the main tasks performed by the users of
the system.
• Use Cases describe the behavioral aspects of the system.
• Use Cases are used to identify how the system will be
used.
• Use Cases are a convenient way to document the
functions that the system must support.
• Use Cases are used to identify the components (classes)
of the system.

17. Use Cases
• Normally, use cases are independent of each other
• Implicit dependencies may exist
• Example: In Library Automation System, renew-book and
reserve-book are independent use cases.
– But in actual implementation of renew-book--- A check is
made to see if any book has been reserved using
reserve-book.
• Other Possible Use Cases in Library information system
– issue-book
– query-book
– return-book
– create-member
– add-book, etc.

18. Representation of Use Cases
• Represented in a use case diagram
– A Use Case is represented by an ellipse
– System boundary is represented by a rectangle
– Users are represented by stick person icons (actor)‫‏‬
– Communication relationship between actor and
Use Case by a line
• External system by a stereotype
Tic-tac-toe game
Play Move

19. Ex1: Draw a Use Case Model
• Video Store Information System supports the
following business functions:
– Recording information about videos the store owns
• This database is searchable by staff and all customers
– Information about a customer’s borrowed videos
• Access by staff and also the customer. It involves video database
searching.
– Staff can record video rentals and returns by
customers. It involves video database searching.
– Staff can maintain customer, video and staff
information.
– Managers of the store can generate various reports.

20. Ex1: Solution
Maintain
Customers
Staff
Rent/Return
Videos
Maintain
Videos
Generate
Reports
Customer
Manager
Search for
Videos
«include»
«include»
Video Store Information System

21. Development of a Use Case Diagram
• Identify all of the actors who will use the system.
• Interview these actors to identify the functions that
they need to perform. (use cases)
• Identify scenarios (sequence of steps to accomplish a
use case).
• Identify common steps within the different scenarios.
Separate them into different use cases so that they
can easily be included in other scenarios.
• Identify relationships between use cases.

22. Actors
• Actor - an entity external to the system that in some
way participates in the use case. Actor represents a
role that a user can play.
• An actor typically stimulates the system with input
events or receives outputs from the system or does
both.
• Actors are treated like classes and can be generalized.
• Primary actor: Use the system to achieve a goal.
(found in left side of the use case diagram)
• Secondary actor: plays a supporting role to facilitate
the primary actor to achieve their goal. (right side)

23. Identification of Use Cases
• Actor-based:
– Identify the actors related to a system or
organization.
– For each actor, identify the processes they initiate or
participate in.
• Event-based
– Identify the external events that the system must
respond to.
– Relate the events to actors and use cases.

24. Factoring Use Cases
• Two main reasons for factoring:
– Complex use cases need to be factored into simpler
use cases
– To represent common behaviour across different
use cases
• Three ways of factoring:
– Generalization
– Include
– Extend

25. Generalization
• The child use case inherits the behaviour of the parent
use case.
– The child may add to or override some of the
behavior of its parent.
parent
child
Registration
Graduate
registration
Under-graduate
registration

26. Include
• When you have a piece of behaviour that is similar
across many use cases
– Break this out as a separate use-case and let the
other ones “include” it
• Examples of use case include
– Validate user interaction
– Sanity check on sensor inputs
– Check for proper authorization
Base use case Common
use case
<<include>>
Issue Book
Check
Reservation
Renew Book
<<include>>
<<include>>

27. Extends
• Use when a use-case optionally can do a little bit
more:
– Capture the normal behaviour
– Capture the extra behaviour in a separate use-case
– Create extends dependency
• Makes it a lot easier to understand
Order
Item
Show
Catalog
<<extend>>

28. Example
Place Order
Supply
Customer Data
Order
Product
Arrange
Payment
Request
Catalog
<<include>>
<<include>>
<<include>>
<<extend>> Salesperson asks for catalog
Sales Person
Cash
Payment
Credit
Payment

29. Ex2: Course Management Software
• At the beginning of each semester,
– Each professor shall register the courses that he is going
to teach.
• A student can select up to four-course offerings.
– During registration a students can request a course
catalogue showing course offerings for the semester.
– Information about each course such as professor,
department and prerequisites would be displayed.
– The registration system sends information to the billing
system so the students can be billed for the semester.
• For each semester, there is a period of time during which
dropping of courses is permitted.
• Professors must be able to access the system to see which
students signed up for each of their course offerings.

30. Register
offering
Show
registration
Register
course
Drop Course
Student
Calendar
Course Management Software
Ex 2: Solution
See Course
List
Professor
<<Extend>>
<<External>>
Billing System

31. Use-Case Model using Packaging

32. UML Class Diagrams

33. Thank You

34. Class
• A class represents a set of objects having similar
attributes, operations, relationships and behaviour.
• Instances are objects
• Template for object creation
• Considered as abstract data type (ADT)‫‏‬
– Examples: Employees, Books, etc.
• Sometimes not intended to produce instances:
– Abstract classes

35. Methods & Messages
• Operations supported by an object:
– Means for manipulating the data of other objects.
– Invoked by sending a message (method call).
– Examples: calculate_salary, issue-book,
member_details, etc.

36. Inheritance
• Allows to define a new class
(derived class) by extending
or modifying existing class
(base class).
• Represents generalization-
specialization relationship.
• Allows redefinition of the
existing methods (method
overriding).
• Types
– Single/Simple; multilevel
– Multiple
LibraryMember
ResearchPostGradUnderGrad
StaffStudentsFaculty
Base Class
Derived
Classes

37. Association
• Enables objects to communicate with each other:
– Thus one object must “know” the address of the
corresponding object in the association.
• Usually binary:
– But in general can be n-ary.
Library Member Book
1 *borrowed by

38. Aggregation
• Represents whole-part relationship
• Represented by a diamond symbol at the composite
end
• Cannot be reflexive(i.e. recursive)‫‏‬
• Not symmetric
• It can be transitive
Document Line
* Paragraph 1 *

39. Composition
• A stronger form of aggregation
– The whole is the sole owner of its part.
• A component can belong to only one whole
– The life time of the part is dependent upon
the whole.
• The composite must manage the creation and
destruction of its parts.
Order
1 *
Item

40. Dependency
• Dependency relationship can arise due to a variety of
reasons:
– Stereotypes are used to show the precise nature of
the dependency.
Type of
dependency
Stereotype Description
Abstraction «abstraction» Relates two model elements, that represent
the same concept at different levels of
abstraction
Binding «bind» Connects template arguments to template
parameters to create model elements from
templates.
Realization «realize» Indicates that the client model element is an
implementation of the supplier model element
Substitution «substitute» Indicates that the client model element
takes place of the supplier.

41. Polymorphism
• Denotes poly (many) morphism (forms).
• Under different situations:
– Same message to the same object can result in
different actions:
• Static binding
• Dynamic binding

42. Genericity
 Ability to parameterize class definitions.
 Example: class stack of different types of elements:
 Integer stack
 Character stack
 Floating point stack
 Define generic class stack:
 Later instantiate as required

43. Thank You