1 / 15

Lab 04

Lab 04. What is Class diagram?. A class diagram shows the existence of classes and their relationships in the logical view of a system UML modeling elements in class diagrams are: Classes, their structure and behavior.

rachel
Download Presentation

Lab 04

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lab 04

  2. What is Class diagram? • A class diagram shows the existence of classes and their relationships in the logical view of a system • UML modeling elements in class diagrams are: • Classes, their structure and behavior. • relationships components among the classes like association, aggregation, composition, dependency and inheritance • Multiplicity and navigation indicators • Role names or labels.

  3. Major Types of classes: Concrete classes • A concrete class is a class that is instantiable; that is it can have different instances. • Only concrete classes may be leaf classes in the inheritance tree. Abstract classes • An abstract class is a class that has no direct instance but whose descendants classes have direct instances. • An abstract class can define the protocol for an operation without supplying a corresponding method we call this as an abstract operation. • An abstract operation defines the form of operation, for which each concrete subclass should provide its own implementation.

  4. RELATIONSHIP: • Association • Aggregation • Composition • Inheritance • Dependency • Instantiation

  5. CUSTOMER ATM system ASSOCIATION: These are the most general type of relationship: • It denotes a semantic connection between two classes • It shows BI directional connection between two classes • It is a weak coupling as associated classes remain somewhat independent of each other • Example:

  6. AGGREGATION: This is a special type of association • The association with label “contains” or “is part of” is an aggregation • It represents “has a “ relationship • It is used when one object logically or physically contains other • The container is called as aggregate • It has a diamond at its end • The components of aggregate can be shared with others • It expresses a whole - part relationships

  7. AGGREGATION: Example: ATM card Customer

  8. COMPOSITION: This is a strong form of aggregation • It expresses the stronger coupling between the classes • The owner is explicitly responsible for creation and deletion of the part • Any deletion of whole is considered to cascade its part • The aggregate has a filled diamond at its end Window Client Area

  9. INHERITANCE: • The inheritance relationship helps in managing the complexity by ordering objects within trees of classes with increasing levels of abstraction. Notation used is solid line with arrowhead,shown below. • Generalization and specialization are points of view that are based on inheritance hierarchies. Account CurrentAccount SavingAccount

  10. Client Server DEPENDENCY: • Dependency is semantic connection between dependent and independent model elements. • This association is unidirectional and is shown with dotted arrowhead line. • In the following example it shows the dependency relationship between client and server. • The client avails services provided by server so it should have semantic knowledge of server. • The server need not know about client.

  11. Element Queue Queue<int> INSTANTIATION This relationship is defined between parameterized class and actual class. • Parameterized class is also referred as generic class. • A parameterized class can’t have instances unless we first instantiated it Example:

  12. What is Cardinality? : Definition: Number of instances of each class involved in the dialogue is specified by cardinality. • Common multiplicity values: • Symbol Meaning • 1 One and only one • 0..1 Zero or one • M…N From M to N (natural integer) • 0..* From zero to any positive integer • 1..* From one to any positive integer • Also thought can be given about navigability to every applicable relationship.

  13. Reaching the class diagram: • In collaboration diagram we have shown the objects, their interaction and detailed message signature. • This information is carried forward to the class diagram. • At this point,we group the similar objects and form classes. • Messages get mapped to responsibilities for respective classes. • Find the attributes for every class. • Transform the links to appropriate relationships. • Relationship is further refined with respect to multiplicity and navigability. This complete procedure brings the minimal class diagram [for withdraw cash use case, normal flow.]

  14. Class diagram[for withdrawal of cash, normal flow] Customer 1 1 1..* 1..* 1..* 1..* ATMSystem 0..* 0..* Transaction 1 1 1 1 1..* 1..* Bank[Branch] 1 1

  15. What more to the Class Diagram? • Till this slide we have worked out the essentials of class diagram for withdrawal of cash use case, normal flow of events. • Similar exercise required to be carried out for every scenario and clubbed all in the class diagram. • At this point, we refine this integrated class diagram to add further fine details. Approximate sketch for this class diagram has been shown at the end of this module. • Refinement attributes should be updated right from sequence diagram to class diagram. • Next few slides will take into the discussion of refinement attributes. • This process of iterative and incremental development will continue till there is no change in two consecutive iteration.

More Related