Class Diagrams

1. Class Diagrams

3. Terms and Concepts • A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and their relationships. • Graphically, a class diagram is a collection of vertices and arcs.

4. Common Properties • A class diagram is just a special kind of diagram and shares the same common properties as do all other diagrams • A name and graphical content that are a projection into a model.

5. Contents • Class diagrams commonly contain the following things: Classes Interfaces Collaborations Dependency, generalization, and association relationships

6. Like all other diagrams, class diagrams may contain notes and constraints. • Class diagrams may also contain packages or subsystems, both of which are used to group elements of your model into larger chunks.

7. Common Uses • We use class diagrams to model the static design view of a system. • This view primarily supports the functional requirements of a system - the services the system should provide to its end users

8. When we model the static design view of a system, we typically use class diagrams in one of three ways. • To model the vocabulary of a system • To model simple collaborations • To model a logical database schema

9. Common Modeling Techniques Modeling Simple Collaborations • Identify the mechanism we would like to model. A mechanism represents some function or behavior of the part of the system we are modeling that results from the interaction of a society of classes, interfaces, and other things. • For each mechanism, identify the classes, interfaces, and other collaborations that participate in this collaboration. Identify the relationships among these things, as well. • Use scenarios to walk through these things. Along the way, we will discover parts of model that were missing and parts that were just plain semantically wrong. • Be sure to populate these elements with their contents. For classes, start with getting a good balance of responsibilities. Then, over time, turn these into concrete attributes and operations.

11. Modeling a Logical Database Schema • Identify those classes in model whose state must transcend the lifetime of their applications. • Create a class diagram that contains these classes and mark them as persistent (a standard tagged value). We can define our own set of tagged values to address database- specific details. • Expand the structural details of these classes. In general, this means specifying the details of their attributes and focusing on the associations and their cardinalities that structure these classes. • Watch for common patterns that complicate physical database design, such as cyclic associations, one-to-one associations, and n-ary associations. Where necessary, create intermediate abstractions to simplify your logical structure. • Consider also the behavior of these classes by expanding operations that are important for data access and data integrity. In general, to provide a better separation of concerns, business rules concerned with the manipulation of sets of these objects should be encapsulated in a layer above these persistent classes. • Where possible, use tools to help us transform our logical design into a physical design.

13. Forward and Reverse Engineering To forward engineer a class diagram • Identify the rules for mapping to your implementation language or languages of choice. • Depending on the semantics of the languages we choose, may have to constrain our use of certain UML features.

14. Use tagged values to specify your target language. • Use tools to forward engineer your models.

16. To reverse engineer a class diagram, • Identify the rules for mapping from our implementation language or languages of choice. • Using a tool, point to the code to reverse engineer. Use tool to generate a new model or modify an existing one that was previously forward engineered. • Using tool, create a class diagram by querying the model.