Distributed Java Programming Distributed Java Programming Class #2 August 22, 2002

Distributed Java Programming Agenda  Quick Review of Use Case Analysis  Class Diagrams  Simple Class Diagrams  Generalization (Inheritance)  Associations  Aggregation and Composition  Constraints  Packages  Sequence Diagrams

Distributed Java Programming What is a Class Diagram?  Attributes  Methods  Access levels of the said properties and methods.  Relationships that exist between object:  Associations  Inheritance A class diagram captures information about the objects that will be used in a in system. Specifically a class diagram captures information about an Objects attributes and properties:

Distributed Java Programming The Basic Object

Distributed Java Programming Access Levels + Public - Private # Protected

Distributed Java Programming Inheritance, Abstract Classes, Interfaces  Concrete and abstract classes you are extending functionality.  Interfaces – You are implementing functionality.  These notations capture generalization. The “is a” relationship between objects.

Distributed Java Programming Associations, Multiplicity and Navigability  A customer accesses one or more accounts.  An account contains zero or more transactions.  Transactions is only be navigable from Accounts.

Distributed Java Programming Associations  Associations are a means of representing relationships that exist between classes.  Captures “has a” relationships between objects.  Associations capture the multiplicity (sometimes referred to as the cardinality) between classes  An association can have names to help clarify the relationship between object instances.  Association ends can also have more human readable names (called roles) at each end of the association.

Distributed Java Programming Multiplicity  Multiplicity is very much like the concept of cardinality in an Entity-Relationship model.  0..1  1..1  10  0..*  When you are doing your modeling make sure you have methods that reflect the association being modeled.  Usually presence of multiplicity will be implemented by having a Java collection object in the class containing references to the children objects.

Distributed Java Programming Navigability  Used to enforce how and when objects are accessed.  Can be bi-directional. In the case of a bi- directional relationship an Order can see all of its line items, but each line item has a method that can be used to return back to original item.  Clearly marking associations, multiplicity and navigability in your diagram can significantly improve the readability of code.  It also makes for more complete code generation.

Distributed Java Programming Aggregation and Composition  Associations show relationships between objects in a system.  There are tighter forms associations:  Aggregation - Aggregation represents an object is “part-of” something. A good example of aggregation would be a car. A car could be considered an object that is made up of many other objects (engine, transmission, wheels).  Composition – Composition is a much stronger form of aggregation. The part object can not exist outside of the whole. For instance an account is made up of 0 or more transactions. However, a transaction can not exist outside the concept of an account. (I.E. I delete an account object, I also have to delete all of its transaction objects)

Distributed Java Programming Aggregation and Composition Examples In the above diagram we are showing two things:  To a bank a customer is composed of one or more accounts. To make the model stretch we could say that an account could belong to more than one customer (joint accounts, business partners, etc…) The open triangle represents composition.  With transactions we show aggregation. Here we say a transaction is part of an account, but it can not belong to more than one account.

Distributed Java Programming Constraints  A constraint is a simple notation in the diagram that demonstrates an important business rule that must be enforced.  Constraints often match the pre and post conditions defined in our use cases.  Do no go overboard with applying constraints. They should only be used for important, noteworthy events. Otherwise the class diagram gets to muddied.

Distributed Java Programming Granularity  Often times large class diagrams can be overwhelming.  UML provides a notation that allows you to group classes together into higher levels of units that are more understandable.  This notation is called a package in UML.

Distributed Java Programming Package Diagram  Packages hide details.  They capture dependencies. The above diagram shows that changes in package B might require changes in package A.  When generating code, packages are used to translate into Java class packages.

Distributed Java Programming In Summary  Use the 80% for object modeling.  Do not overanalyze.  The more detail you do catch in your model, the more the code will generate for you.  A class diagram is a living document, keep it up to date or it becomes useless.

Distributed Java Programming Tonight’s Lab The class will break into four groups. Each group will build a class diagram with properties and methods for a customer and their accounts.  Install Poseidon UML  Demonstrate Inheritance in your model  Properly capture the associations, multiplicity and navigability.  Generate source code and look at the results.

Distributed Java Programming Resources Martin Fowler UML Distilled Second Edition Safari.informit.com Poseidon UML UML Resource Center