Object-Oriented Modeling Using Modified Modeling Language (UML)

1
Object-Oriented Modeling Using Modified Modeling
Language(UML)
2
Outline

• Unified Modeling Language
• Principles and Concepts
• Modeling Relations and Structures
• Modeling Dynamic Behavior
• Modeling Requirements with Use Cases

3
What is a Model?

• A model is a simplification of reality.
• A model may provide
• blueprints of a system
• Organization of the system
• Dynamic of the system

4
Why We Model

• A successful software organization is one that
  consistently deploys quality software that meets
  the needs of its users. An organization that can
  develop such software in a timely and predictable
  fashion, with an efficient and effective use of
  resources, both human and material, is one that
  has sustainable business.

5
Why We Model

• Model is built to
• Communicate the desired structure and behavior of
  the system
• Visualize and control the systems architecture
• Better understand the system that being built
• Manage risk
• Expose opportunities for simplification and reuse

6
Why We Model

• We build models so that we can see and better
  understand the system we are developing.

7
Importance of Modeling

• Models help us
• to visualize a system as it is or as we want it
  to be.
• to specify the structure or behavior of a system.
• in providing a template that guides us in
  constructing a system.
• in providing documenting the decisions we have
  made.

8
Principles of Modeling

• The choice of what models to create has a major
  influence on how a problem is approached and how
  a solution is shaped.
• Every model may be expressed at different levels
  of precision.
• The best models are connected to reality.
• No single model is sufficient. Every nontrivial
  system is best approached through a small set of
  nearly independent models.

9
Objected-Oriented Modeling

• Two most common ways in modeling software systems
  are
• Algorithmic
• Procedures or functions
• Object oriented
• Objects or classes

10
What is UML?

• UML is a language for
• Visualizing
• Specifying
• Constructing
• Documenting

11
Building Blocks of UML

• Things -- abstraction
• Relations -- tie things together
• Diagrams -- group interesting collections of
  things

12
Principles and Concepts

• Objects and Classes
• Principles

13
Objects and Classes
Interpretation in the Real World Interpretation in the Model
Object An object is a thing that can be distinctly identified. An object has an identity, a state, and a behavior.
Class A class represents a set of objects with similar characteristics and behavior. This objects are called the instances of the class. A class characterizes the structure of states and behaviors that are shared by all instances.
14
Objects

• Each of object has a unique identity.
• The state of an object is composed of a set of
  fields (data fields), or attributes.
• Each field has a name, a type, and a value.
• Behaviors are defined by methods.
• Each method has a name, a type, and a value.
• Each method may or may not return a value.
• Features are a combination of the state and the
  behavior of the object.

15
Properties of Objects

• Two objects are equal if their states are equal.
• Two objects are identical if they are the same
  objects.
• The values of the fields are mutable.
• Methods that do not modify the state of the
  object are called accessors.
• Methods that modify the state of the object are
  called mutators.
• Objects can be mutable or immutable.

16
Classes

• A class defines a template for creating or
  instantiating its instances or objects.
• A class is a description of a set of objects that
  share the same attributes, operations,
  relationships, and semantics.

17
Classes

• A class defines --
• the names and types of all fields
• the names, types, implementations of all methods
• The values of the fields are not defined or fixed
  in the class definition.
• The values of the fields are mutable.
• Each instance of the class has its own state.
• Different instances of the class may have
  different states.
• The implementations of methods are defined in the
  class definition and fixed for a given object.
• Values of methods are immutable

18
Example

• Class name Point class Point
• Fields x, y int x, y
• Method move public void move
• (int dx, int dy)
• // implementation

19
UML Notation for Classes
ClassName The top compartment shows the class name.
field1 fieldn The middle compartment contains the declarations of the fields of the class.
method1 methodm The bottom compartment contains the declarations of the methods
20
Field Declaration

• The name of the field is required in the field
  declaration.
• Field declaration may include
• VisibilityTypeNameMultiplicityInitialVal
  ue
• VisibilityNameMultiplicityTypeInitialVa
  lue
• Visibility or accessibility defines the scope
• Public -- the feature is accessible to any class
• Protected -- the feature is accessible to the
  class itself, all the classes in the same
  package, and all its subclasses.
• Package -- the feature is accessible to the class
  itself and all classes in the same package.
• Private -- the feature is only accessible within
  the class itself.

21
Visibility syntax in Java and UML
Visibilty Java Syntax UML Syntax
public public
protected protected
package
private private -
22
Examples
Java Syntax UML Syntax
Date birthday BirthdayDate
Public int duration 100 durationint 100
Private Student students0..MAX_Size -students0..MAX_SizeStudent
23
Method Declaration

• The name of the method is required in the method
  declaration.
• Method declaration may include
• VisibilityTypeName(Parameter, ...)
• VisibilityName(Parameter, ...)Type
• Each parameter of a method can be specified by --
  Type Name

24
Examples
Java Syntax UML Syntax
void move(int dx, int dy) move(int dx, int dy)
public int getSize() int getSize()
25
Example
Point
private int x private int y
public void move(int dx,int dy)
Point
-xint -yint
move(dxint,dyint)
Point
x y
move()
26
UML Notation for Object
ObjectName ClassName The top compartment shows the object name and its class.
field1 value1 fieldn valuen The bottom compartment contains a list of the fields and their values.
objectName -- objectName whose class is of no interest ClassName -- anonymous object of ClassName which can be identify only through its relationship with other object. objectName -- objectName whose class is of no interest ClassName -- anonymous object of ClassName which can be identify only through its relationship with other object.
27
Examples
P1Point Point p1 new Point()
x 0 y 0 p1.x 0 P1.y 0
P1Point Point p1 new Point()
x 24 y 40 p1.x 24 P1.y 40
28
Message Passing orMethod Invocation

• Objects communicate with one another through
  message passing.
• A message represent a command sent to an object
  -- recipient
• A message consists of the receiving object, the
  method to be invoked and the arguments to method.

29
Example
p1.move(10,20) Recipient p1
p1.move(10,20) Method move()
p1.move(10,20) Arguments (10,20)
30
Packages

• Package name are in lower case --
• Java.awt.event
• javax.swing.
• Packages that will be widely used should be named
  as the reverse of the internet domain as the
  prefix of the package name --
• EDU.emporia.mathbeans.MathTable
• EDU.emporia.mathtools.

31
UML notation of packages
32
Principles

• Modularity
• alleviate complexity of large-scale systems
• Abstraction
• separating the essential from the non-essential
  characteristics of an entity
• Encapsulation
• Information hiding
• Polymorphism
• Portability
• Levels of Abstraction
• Organization of classes and interfaces

33
Principle of Modularity

• A complex software system should be decomposed
  into a set of highly cohesive but loosely coupled
  modules.
• The basic for decomposition are cohesion and
  coupling.
• Cohesion -- functional relatedness of the
  entities within modules.
• Coupling inter-dependency among different
  modules.
• Each module is relatively small and simple
• Interactions among modules are relatively simple
• hierarchical

34
Principle of Abstraction

• The behaviors or functionalities should be
  precisely characterized as contractual interface
  which captures the essence of the behavior.
• The complexity of the module is hidden from the
  clients.

35
Principle of Encapsulation

• The implementation of a module should be
  separated from its contractual interface and
  hidden from the clients of the module.
• Information hiding

36
Principle of Polymorphism

• Ability to interchange modules dynamically
  without affecting the system.
• refers to a contractual interface with multiple
  interchangeable implementation

37
Modeling Relationships and Structures

• A class diagram consists of
• A set of nodes that represent classes and
  interfaces
• A set of links represent relationships among
  classes
• Class diagrams can be used to model
• Inheritance -- extension and implementation
• Association -- aggregation and compostion
• Dependency

38
Inheritance

• Define a relationship among classes and
  interfaces
• Inheritance model -- the is-a(n) relationship

39
Example
40
Principle of Levels of Abstraction

• Abstractions can be organized into different
  levels.
• Higher level is more general

41
Association

• Association represents binary relationship
  between classes

enroll

Student
Course
advisee


teach
1
1
Faculty
adviser
42
Aggregation and Compositon

• Aggregation is a special form of association
• Has-a or part-whole relationship
• Composition is a stronger form of aggregation

43
Example
1
1
1



University
Department
College
Student
1
1
Chairman-of
Member-of
1
1..
Faculty
44
Dependency

• Dependency is a relationship between entities
  such that the proper operation of one entity
  depends on the presence of the other entity, and
  changes in one entity would affect the other
  entity.

45
Example
CourseSchedule
Registrar

void addCourse(CourseSchedule a, Course c) void removeCourse(CourseSchedule Course findCourse(String title) void enroll(Course c, Student s) void drop(Course c, Student s
Course
Student
46
Modeling Dynamic Behavior

• Sequence diagram
• Depict object interaction by highlighting the
  time ordering of method invocation

47
Example
48
Modeling Dynamic Behavior

• State diagram
• Depict the flow of control using the concepts of
  state and transitions
• Labels of transitions are in the form
• Event-ListGuard/Action
• Entry action and exit action
• entry/Action1
• exit/Action2

49
Graphical notations
50
Modeling Dynamic Behavior

• Nested state diagram
• Composite of state diagrams

51
Example
talk
52
Modeling Requirements with Use Cases

• Use cases describes the externally observable
  behavior of system functions in the form of
  interactions between the system to be developed
  and the external entities -- Actors.
• Actors may represent roles played by users of the
  system or other systems.
• Consist of a name and scenarios
• One of scenarios is the main scenario

53
Use Case Diagram

• Consist of
• Use cases
• Actors
• Relationships among actors and use cases

54
Extension relationships among actors
55
Dependency relationships among use cases
56
Case Study An E-Bookstore

• Problem requirements
• Program specifications
• Object models
• Identifying classes
• Identifying the features of classes -- states and
  behaviors
• Identifying relationships among classes
  inheritance and interfaces.

57
Requirements

• Allow customers to browse and order books, music
  CDs, and computer software

58
Specifications

• Provide information on the books, CDs, and
  software
• Provide a functionality for customers
  registration as well as updating customers
  information
• Provide a functionality for ordering and shipping
• Provide a functionality for updating inventory

59
Register
Logon
Manager
Manage catalog
Customer
Shop
Catalog Manager
ManageAcount
Process order
System administrator
Inventory manager