unified modeling language (uml) “ a language for specifying, visualizing, and constructing the...
TRANSCRIPT
Unified Modeling Language (UML)
“ a language for specifying, visualizing, and constructing the artifacts of software systems, as well as for business modeling”
• unification of Booch, Jackobson and Rumbaugh modeling approaches
• graphical depiction of O-O analysis and design models– Use cases: functional reqts. (what)– Class diagrams: static structure of objects, their data and
operations– State diagrams: dynamic models of objects change their
state in response to events– Sequence diagrams: dynamic models of interaction
between objects
Benefits of O-O modeling• Increased consistency among models developed for analysis,
design and programming
• Improved communication among users, analysts, designers, programmers
• Explicit representation of commonality among system components
• Reusability of analysis, design and programming results
• Robustness of systems
• Ability to tackle more challenging problem domains
StudentnamedateOfBirthyearaddressphone
calc_age()
calc_gpa()
register(course)
Course
codedepttitlecreditHours
enrollment()
prereqs()
:Course
code=IDS405dept=IDStitle=blah_blahcreditHours=3
J.Daniels:Student
name=Jack DanielsdateOfBirth=01/01/99year=senior
Anatomy of a class
Encapsulation:All information is packaged under one name, and can be reused as one specification or program component
Information hidingAttributes of a class can be accessed only through the class operations/methods/services (external interface for a class)
• Reduced impact of side effects of changes• More cohesive methods• Class is de-coupled from other parts of system
Attributes
Operations/methods
State of an object:
values for attributes, and links to other objects
Object identity
Operations
(service provided by an object to its client)
• Constructor: creates a new instance of an object-class
• Query: does not change state of object, no side-effects. -no need to explicitly show operation like get_name() -target object is always an implicit argument
• Update: alters the state of an object
Customer
Order Product
Product Line
Places
Requests
Includes
1
** 1..*
1..*
1
Class Diagram (ORD) : object-class associations
Object Diagram: instance diagram - graph of instances that is compatible with a given class diagram.
:Customer A
:Customer A:Customer A
:Order 1:Order 1 :Order 1
:Product A2 :Product A6
:Product P2
:Product P5 :Product X6
:Product Line A :Product Line P :Product Line X
Object (Instance)diagram
Student Coursetutor
pupilTutors
**
beginDatenumHours
termgrade
Registration
CheckEligibility()
acctNumpasswordserverSpace
AccountIssues
* *
* 0..1
Software
Student Course
Log
beginDateexpirydatehoursLogged
estimateUsage()
tool
user forum
*
*
*
Student
NamessndateOfBirth/age
Course Offeringtermsection
Course
/participants
registrants
Registers-for
* *
Scheduled-for
* 1..*
**
CodetitlecrdHours
{age = currentDate - dateOfBirth}
Derived attribute, association
Student {abstract}
NamessndateOfBirth
Course Offeringtermsection
Course
registrants
Registers-for
* *
Scheduled-for
* 1..*
CodetitlecrdHours
register-for(class)calc_tuition()
Grad-Student
ugMajorgreScoretuition=300
Calc_tuition()
UG-Student
satScoreactScoretuition=250
Calc_tuition()
• Abstract class• Concrete class• Abstract operation polymorphism
enrollment() enrollment()
University
Admn.Unit School
Department
Building
Room
1
1..* 1..*
1
*
1 1
1
20..*
Aggregation
Composition
Composition: part belongs to only a single whole, and dies with the whole
Object Communication Through Message Passing:
Message: request sent by an object for the services/assistance of a second object. Receiving object responds by choosing appropriate method, executing it and returning control to caller.
E.g.: Customer wants to check status of an order
CustomerOrder
O#ODate
O-Status...
AddOrder()ModifyOrder()
DisplayStatus()...
Message request
Display Statusof order#1267
POLYMORPHISM:
Same named behavior may be completed differently for different object classes
Bank Account
PassbookAccount
Saving InvstAccount
Saving Account
CheckingAccount
Customer
Withdraw()
Withdraw()
Withdraw()
Withdraw()
Withdraw()
Bank Acct XX: Withdraw()
1*
Rental Order Line
Due-Date
Rental Category
Rental Tape
TapeName
Rental Order
RO#
Object Behavior design
•Assign methods to classes
•Method Determine DueDate ----- Which Class ?
Assigning Methods to Classes :– try to assign method to class that knows the
required attributes– assign method to class that is logically expected t
perform the method
Object Behavior Analysis: some guidelines
• Methods should be distributed fairly evenly among classes, so that you avoid having a few “control” objects and many “data” objects
• When possible, assign method to class that knows the attributes needed to perform the method– when no single class knows all the attributes needed,
assign method to the class that would be logically expected to perform the method
Guidelines [contd]
• Methods used to create and break relationships should be assigned to the class that controls the relationship
• Method that changes the state of an object should be assigned to the class.
• When in doubt, act it out!
Rental Customer
Authorized User
Rental customer can exist without be associated with Authorized User, but not vice-versa.So, method AddAuthorizedUser() should be assigned to Rental Customer (the controlling class)
Two classes: Account and Payment. A method reportStatus(..) returns values “overdue” or “paid”. Which class should contain this method?
Example
Example
Example
A method calcExtendedPrice(..) multiplies the quantity of a line item by the price of the line item. Quantity is an attribute of LINE-ITEM and price is an attribute PRODUCT. Should this method be assigned to LINE-ITEM or PRODUCT?
Example
Method addAccount() creates a relationship between a Customer instance and an Account instance. Each customer can be related to zero or many Accounts objects, but each Account object must be related to exactly one Customer object.Which class should this method be assigned to?
Evaluating Object-behavior design
• Present functionality vs. future adaptability (reusability)• Coupling:
– should not have to pass a lot of data between objects - no message should need more than three parameters
– No messages should be sent from sub-classes to access data in a super-class - taken care of by inheritance.
– Coupling is a natural side-effect of specialization and composition relationships - however, collaboration relationships should not be so strong that Class-A and useless without Class-B.
• Cohesiveness– single functionality per methodEg. completeOrderFooter(..) that also prints the order
- two separate methods better
– overriding of attributes and methods defined in a super-class should not be too frequent.
• Clarity
• Complexity vs. reusability– neither too deep, nor too wide
Evaluating Object-behavior design [contd.]
Evaluating Object-behavior design [contd.]
• Simplicity– should not have too many methods in a class
• 5 or 6; number of attributes less than twice number of methods
– too many methods signify an application specific definition of a class, which will be difficult to reuse.
• “Act-ability”– high quality OO design can be acted out be humans playing
the role of objects
– can be verified by a structured walk-through
– mappings between real-world objects and system objects should be transparent.