Unit_1_IntroductionToCG.pdf

OOAD UNIT -3 : Class Diagram, Object Diagram, Sequence Diagram Contents of UNIT 3 Class Diagram Object Diagram Sequence Diagram Different Types Of UML diagrams Class Diagrams - Introduction Class Diagram: A class diagram in the Unified Modeling Language (UML) is a type of static structur...

OOAD UNIT -3 : Class Diagram, Object Diagram, Sequence Diagram Contents of UNIT 3 Class Diagram Object Diagram Sequence Diagram Different Types Of UML diagrams Class Diagrams - Introduction Class Diagram: A class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects. Class diagrams are the only diagrams which can be directly mapped with object-oriented languages and thus widely used at the time of construction. In these diagrams, classes are depicted as boxes, each containing three compartments for the class name, attributes, and methods. Lines connecting classes illustrate associations, showing relationships such as one-to-one or one-to-many. Class Diagrams - Introduction Class diagrams provide a high-level overview of a system’s design, helping to communicate and document the structure of the software. They are a fundamental tool in object-oriented design and play a crucial role in the software development lifecycle. In object-oriented programming (OOP), a class is a blueprint or template for creating objects. Objects are instances of classes, and each class defines a set of attributes (data members) and methods (functions or procedures) that the objects created from that class will possess. The attributes represent the characteristics or properties of the object, while the methods define the behaviors or actions that the object can perform. Class Diagrams - Introduction Purpose of Class Diagrams This is the only UML that can appropriately depict various aspects of the OOPs concept. Proper design and analysis of applications can be faster and efficient. It is the base for deployment and component diagram. It incorporates forward and reverse engineering. Class Diagrams – Analysis & Design Class diagrams are useful in many stages of system design. In the analysis stage, a class diagram can help you to understand the requirements of your problem domain and to identify its components. In an object-oriented software project, the class diagrams that you create during the early stages of the project contain classes that often translate into actual software classes and objects when you write code. Later, you can refine your earlier analysis and conceptual models into class diagrams that show the specific parts of your system, user interfaces, logical implementations, and so on. Class Diagrams – Analysis & Design Your class diagrams then become a snapshot that describes exactly how your system works, the relationships between system components at many levels, and how you plan to implement those components. You can use class diagrams to visualize, specify, and document structural features in your models. During the implementation phase of a software development cycle, you can use class diagrams to convert your models into code and to convert your code into models. Class Diagrams – Analysis & Design For example, during the analysis and design phases of the development cycle, you can create class diagrams to perform the following functions: Capture and define the structure of classes and other classifiers Define relationships between classes and classifiers Illustrate the structure of a model by using attributes, operations, and signals Show the common classifier roles and responsibilities that define the behavior of the system Show the implementation classes in a package Show the structure and behavior of one or more classes Show an inheritance hierarchy among classes and classifiers Show the workers and entities as business object models Class Diagrams – Analysis & Design Class Diagrams – Elements Class Name: The name of the class is typically written in the top compartment of the class box and is centered and bold. Attributes: Attributes, also known as properties or fields, represent the data members of the class. They are listed in the second compartment of the class box and often include the visibility (e.g., public, private) and the data type of each attribute. Methods: Methods, also known as functions or operations, represent the behavior or functionality of the class. They are listed in the third compartment of the class box and include the visibility (e.g., public, private), return type, and parameters of each method. Class Diagrams – Elements Visibility Notation: Visibility notations indicate the access level of attributes and methods. Common visibility notations include: + for public (visible to all classes) - for private (visible only within the class) # for protected (visible to subclasses) ~ for package or default visibility (visible to classes in the same package) Class Diagrams – Elements Class Diagrams – UML Notations Class Diagrams – UML Notations Class Diagrams – Elements There are three main parameter directionality notations used in class diagrams: In (Input): An input parameter is a parameter passed from the calling object (client) to the called object (server) during a method invocation. It is represented by an arrow pointing towards the receiving class (the class that owns the method). Out (Output): An output parameter is a parameter passed from the called object (server) back to the calling object (client) after the method execution. It is represented by an arrow pointing away from the receiving class. Class Diagrams – Elements InOut (Input and Output): An InOut parameter serves as both input and output. It carries information from the calling object to the called object and vice versa. It is represented by an arrow pointing towards and away from the receiving class. Class Diagrams – Elements Relationships between classes: Class Diagrams – Relationships Simple Association: A structural link between two peer classes. There is an association between Class1 and Class2 A solid line connecting two classes Class Diagrams – Relationships Inheritance (or Generalization): Represents an "is-a" relationship. An abstract class name is shown in italics. SubClass1 and SubClass2 are specializations of Super Class. A solid line with a hollow arrowhead that point from the child to the parent class Class Diagrams – Relationships Aggregation: A special type of association. It represents a "part of" relationship. Class2 is part of Class1. Many instances (denoted by the *) of Class2 can be associated with Class1. Objects of Class1 and Class2 have separate lifetimes. A solid line with an unfilled diamond at the association end connected to the class of composite Class Diagrams – Relationships Composition: A special type of aggregation where parts are destroyed when the whole is destroyed. Objects of Class2 live and die with Class1. Class2 cannot stand by itself. A solid line with a filled diamond at the association connected to the class of composite Class Diagrams – Relationships Dependency: Exists between two classes if the changes to the definition of one may cause changes to the other (but not the other way around). Class1 depends on Class2 A dashed line with an open arrow Class Diagrams – Relationships Multiplicity How many objects of each class take part in the relationships and multiplicity can be expressed as: Exactly one - 1 Zero or one - 0..1 Many - 0..* or * One or more - 1..* Exact Number - e.g. 3..4 or 6 Or a complex relationship - e.g. 0..1, 3..4, 6.* would mean any number of objects other than 2 or 5 Class Diagrams – Relationships Requirement: A Student can take many Courses and many Students can be enrolled in one Course. In the example below, the class diagram (on the left), describes the statement of the requirement above for the static model while the object diagram (on the right) shows the snapshot (an instance of the class diagram) of the course enrollment for the courses Software Engineering and Database Management respectively) How to draw Class Diagram Identify Classes: Start by identifying the classes in your system. A class represents a blueprint for objects and should encapsulate related attributes and methods. List Attributes and Methods: For each class, list its attributes (properties, fields) and methods (functions, operations). Include information such as data types and visibility (public, private, protected). Identify Relationships: Determine the relationships between classes. Common relationships include associations, aggregations, compositions, inheritance, and dependencies. Understand the nature and multiplicity of these relationships. How to draw Class Diagram Create Class Boxes: Draw a rectangle (class box) for each class identified. Place the class name in the top compartment of the box. Divide the box into compartments for attributes and methods. Add Attributes and Methods: Inside each class box, list the attributes and methods in their respective compartments. Use visibility notations (+ for public, – for private, # for protected, ~ for package/default). Draw Relationships: Draw lines to represent relationships between classes. Use arrows to indicate the direction of associations or dependencies. Different line types or notations may be used for various relationships. How to draw Class Diagram Label Relationships: Label the relationships with multiplicity and role names if needed. Multiplicity indicates the number of instances involved in the relationship, and role names clarify the role of each class in the relationship. Review and Refine: Review your class diagram to ensure it accurately represents the system’s structure and relationships. Refine the diagram as needed based on feedback and requirements. Use Tools for Digital Drawing: While you can draw class diagrams on paper, using digital tools can provide more flexibility and ease of modification. UML modeling tools, drawing software, or even specialized diagramming tools can be helpful. Object Diagrams - Introduction An object diagram in the Unified Modeling Language (UML), is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time. Object diagrams represent an instance of a class diagram. The basic concepts are similar for class diagrams and object diagrams. Object diagrams also represent the static view of a system but this static view is a snapshot of the system at a particular moment. Object Diagrams - Introduction Object diagrams are a visual representation in UML (Unified Modeling Language) that illustrates the instances of classes and their relationships within a system at a specific point in time. They display objects, their attributes, and the links between them, providing a snapshot of the system’s structure during execution. Since object diagrams depict behavior when objects have been instantiated, we can study the behavior of the system at a particular instant. An Object Diagram can be referred to as a screenshot of the instances in a system and the relationship that exists between them. Object Diagrams - Purpose The difference is that a class diagram represents an abstract model consisting of classes and their relationships. However, an object diagram represents an instance at a particular moment, which is concrete in nature. It means the object diagram is closer to the actual system behavior. The purpose is to capture the static view of a system at a particular moment. The purpose of the object diagram can be summarized as − Forward and reverse engineering. Object relationships of a system Static view of an interaction. Understand object behaviour and their relationship from practical perspective Object Diagrams – Objects & Links An object refers to a specific instance of a class within a system. A class is a blueprint or template that defines the common attributes and behaviors shared by a group of objects. An object, on the other hand, is a concrete and individual occurrence of that class, possessing unique values for its attributes We use a link to represent a relationship between two objects. The term link is used to specify a relationship between two instance specifications or objects. Object Diagrams – Elements 1. Objects or Instance specifications When we instantiate a classifier in a system, the object we create represents an entity which exists in the system. We can represent the changes in object over time by creating multiple instance specifications. We use a rectangle to represent an object in an object diagram. Object Diagrams – Elements 2. Attributes and Values Inside the object box, attributes of the object are listed along with their specific values. 3. Link We use a link to represent a relationship between two objects. We represent the number of participants on the link for each, at the end of the link. We use a solid line to represent a link between two objects. Object Diagrams – Notations Sequence Diagram: Introduction A sequence diagram is used to express use-case realizations. It shows how objects interact to perform the behaviour of all or part of a use-case. A sequence diagram is a type of interaction diagram because it describes how—and in what order—a group of objects works together. The sequence diagram is used primarily to show the interactions between objects of a system, in the sequential order of the occurrence of interactions. Sequence Diagram The diagram conveys this information along the horizontal and vertical dimensions. The vertical dimension shows, top-down, the time time sequence of messages / calls as they occure The horizontal dimension show, left-right, the object instances that the meesages are sent to. A dynamic modelling diagram focusing on identifying the behaviour of related objects within the system. Sequence diagrams are used to give a picture of the design because they provide a way to visually step through invocation of the operations defined by classes. Sequence diagrams are used to display the interaction between users, screens, objects and entities within the sysem. A sequential map of message passing between objects over time. Sequence Diagram: Elements A Sequence diagram is Two – dimensional in nature. Vertical axis, shows the life of the object that it represents. Horizontal axis, shows the sequence of the creation or invocation of these objects. Elements Life Lines Messages Activation Guards Combined Fragments Objects Sequence Diagram: Lifelines Lifelines represent either roles or instances that participate in the sequence of interaction being modelled. Lifeline notation elements are placed at the top of the diagram. So basically each instance in a sequence diagram is represented by a lifeline. Sequence Diagram: Messages A Message defines a specific kind of communication between instances in an interaction. It represents a method call and invocation between the objects. A message specifies the sender and the receiver, and defines the kind of communication that occurs between lifelines. Communnication can invoke or call using Synchronous Call (synchCall) Asynchronous Call (asynchCall) Sequence Diagram: SynchCall A synchronous message waits for a reply before the interaction can move forward. The sender waits until the receiver has completed the processing of the message. The caller continues only when it knows that the receiver has processed the previous message i.e. it receives a reply message. We use a solid arrow head to represent a synchronous message. Sequence Diagram: AsynchCall An asynchronous message does not wait for a reply from the receiver. The interaction moves forward irrespective of the receiver processing the previous message or not. We use a lined arrow head to represent an asynchronous message. Sequence Diagram: Association Activation boxes represent the time an object needs to complete the task. Activation is created automatically when we create a synchronous or an asynchronous message. Each activation represents an execution in a behaviour. Activation boxes also called, focus of control Sequence Diagram: Gaurds Guards are the conditions used throughout UML diagrams to control flow. When modelling object interactions, there will be time when a conditions must be met for a message to be sent to the object. To display a guard, we place the guard element above the message line being guarded within square brackets and in front of the message name. Sequence Diagram: Messages Sequence Diagram: Combined Fragments Alternatives They are used to make only choice between two or more message sequence. It is “if then else” Drawn using a frame. An alternatives combination fragment element is drawn using a frame. The word “alt” is placed inside the frame’s name box. To have one or more alternative, an operand with that sequence’s guard and messages must be added. Sequence Diagram: Combined Fragments Loops Elements of Sequence Diagram Combined Fragments - Loops The loop combinaton fragment is used to model an iterative sequence. The word “loop” is placed inside the frame’s name box. The guard can have two special conditions having Minimum iterations “minint = [the number]” Maximum iteration “maxint” = [the number]” The loop combinaton fragment is used to model an iterative sequence. The word “loop” is placed inside the frame’s name box Sequence Diagram: Combined Fragments Loops Sequence Diagram: Combined Fragments Objects There are four types of objects which interact with each other in a sequence diagram. Actor Object Boundary Object Controller Object Entity Object If any other type of object is to be shown,then the notation used object name : class name Object : Class Sequence Diagram: Combined Fragments Actor Actor object is an instance of a class which initiates the task. It represents an external person or entity that interacts with the system. Sequence Diagram: Combined Fragments Boundary Elements of Sequence Diagram Objects – Boundary Object Boundary objects, instance of boundary classes, are used to model the interaction between a system and its actors. The boundary class may be a user interface class, system interface class or device interface class. Windows, screens, web pages and menus are examples of boundaries that interface with users. Sequence Diagram: Combined Fragments Countroller Controller objects are used to model the control behaviour specific to one or a few use-cases. Controller objects represent the use case logic and coordinates the other classes. Objects that mediate between boundaries and entities. Serve as the glue between boundary elements and entity elements, implementing the logic required to manage the various elements and their interactions. Examples of control objects include programs, such as transaction managers, resource coordinators and error handlers. Sequence Diagram: Combined Fragments Entity An entity object is used to model information and associated behaviour that must be stored. It used to hold and update information about phenomenon. Such as event, a person or some real-life object Example: Account and customer Sequence Diagram: Combined Fragments Guidelines For each use-case, one sequence diagram is drawn. Always have one boundary class per actor/use case pair, one control class per use-case. Ordering of message sequence is always shown from left to right An actor name must be the same as specified in a use case diagram. An actor can have the same name as a class. Primary actors must be specified on the left-most side of the diagram Reactive system actors must be specified on the right most side of diagram Proactive system actors must be specified on the left most side of diagram. An object can call itself recursively.