Uml

Object-Oriented Modeling Using Modified Modeling Language (UML)
Outline
Unified Modeling Language Principles and Concepts Modeling Relations and Structures Modeling Dynamic Behavior Modeling Requirements with Use Cases
Object-Oriented Modeling Using UML 2
CS 3300 Object-Oriented Concepts
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
Object-Oriented Modeling Using UML
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.
CS 3300 Object-Oriented Concepts Object-Oriented Modeling Using UML 4
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
Why We Model
We build models so that we can see and better understand the system we are developing.
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.
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.
Objected-Oriented Modeling
Two most common ways in modeling software systems are
Algorithmic
Procedures or functions
Object oriented
Objects or classes
What is UML?
UML is a language for
Visualizing Specifying Constructing Documenting
10
Building Blocks of UML

Things -- abstraction Relations -- tie things together Diagrams -- group interesting collections of things
11
Principles and Concepts

Objects and Classes Principles
12
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.
13
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.
14
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.
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.
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
Example
Class name: Point class Point { Fields: x, y int x, y; Method: move public void move (int dx, int dy){ // implementation }
18
UML Notation for Classes

ClassName field1 fieldn method1 methodm The top compartment shows the class name. The middle compartment contains the declarations of the fields of the class. The bottom compartment contains the declarations of the methods
Field Declaration
The name of the field is required in the field declaration. Field declaration may include:
[Visibility][Type]Name[[Multiplicity]][=InitialValue] [Visibility]Name[[Multiplicity]][:Type][=InitialValue]
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.
Visibility syntax in Java and UML

Visibilty public protected package private private Java Syntax public protected UML Syntax + # ~ -
21
Examples
Java Syntax
Date birthday
UML Syntax
Birthday:Date
Public int duration = 100
+duration:int = 100
Private Student students[0..MAX_Size]
-students[0..MAX_Size]:Student
22
Method Declaration
The name of the method is required in the method declaration. Method declaration may include:
[Visibility][Type]Name([Parameter, ...]) [Visibility]Name([Parameter, ...])[:Type]
Each parameter of a method can be specified by -- Type Name

Examples
Java Syntax
void move(int dx, int dy)
UML Syntax
~move(int dx, int dy)
public int getSize()
+int getSize()
24
Example
Point Point -x:int -y:int private int x private int y +move(dx:int,dy:int)
Point x y public void move(int dx,int dy) move()

UML Notation for Object

ObjectName : ClassName field1 = value1 fieldn = valuen The top compartment shows the object name and its class.
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.
Examples
P1:Point Point p1 = new Point();
x = 0 y = 0
p1.x = 0; P1.y = 0;
P1:Point
Point p1 = new Point();
x = 24 y = 40
p1.x = 24; P1.y = 40;
27
Message Passing or Method 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.
Example
Recipient p1
p1.move(10,20) Method
move()
Arguments (10,20)
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.*
UML notation of packages
31
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
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
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.
34
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
35
Principle of Polymorphism
Ability to interchange modules dynamically without affecting the system. refers to a contractual interface with multiple interchangeable implementation
36
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
Inheritance
Define a relationship among classes and interfaces Inheritance model -- the is-a(n) relationship
38
Example
39
Principle of Levels of Abstraction

Abstractions can be organized into different levels. Higher level is more general
40
Association
Association represents binary relationship between classes
Student advisee * * enroll * Course * teach 1 adviser
1 Faculty
41
Aggregation and Compositon

Aggregation is a special form of association
Has-a or part-whole relationship
Composition is a stronger form of aggregation
42
Example
University
College
Department
Student
1 Chairman-of 1
1 Member-of 1..*
Faculty
43
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.
44
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
45
Modeling Dynamic Behavior

Sequence diagram
Depict object interaction by highlighting the time ordering of method invocation
46
Example
47

State diagram
Depict the flow of control using the concepts of state and transitions Labels of transitions are in the form: [Event-List][[Guard]][/Action] - Entry action and exit action entry/Action1 exit/Action2
Graphical notations
49

Nested state diagram
Composite of state diagrams
50
Example
talk
51
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
Use Case Diagram

Consist of:
Use cases Actors Relationships among actors and use cases
53
Extension relationships among actors
54
Dependency relationships among use cases
55
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.
Requirements
Allow customers to browse and order books, music CDs, and computer software
57
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
Register
Logon
Manager
Customer
Shop
Manage catalog Catalog Manager
Manage Acount System administrator

Process order Inventory manager


Uml

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Uml

Hochgeladen von

Copyright:

Verfügbare Formate

Object-Oriented Modeling Using Modified Modeling Language (UML)

CS 3300 Object-Oriented Concepts

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

Building Blocks of UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

Principles and Concepts

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

Objects and Classes

An object is a thing that can be distinctly identified.

An object has an identity, a state, and a behavior.

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

UML Notation for Classes

CS 3300 Object-Oriented Concepts

Visibility or accessibility defines the scope:

Visibility syntax in Java and UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

Public int duration = 100

Private Student students[0..MAX_Size]

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

Each parameter of a method can be specified by -- Type Name

public int getSize()

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

Point x y public void move(int dx,int dy) move()

UML Notation for Object

Point p1 = new Point();

p1.x = 24; P1.y = 40;

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

Message Passing or Method Invocation

UML notation of packages

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

Modeling Relationships and Structures

Class diagrams can be used to model:

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML

CS 3300 Object-Oriented Concepts

Object-Oriented Modeling Using UML