Introduction to Defining Classes in Python Programming
This chapter delves into the significance of defining new classes in Python, providing structure for complex programs. Learn how to write Python class definitions, understand encapsulation, and facilitate building modular and maintainable programs. Explore creating novel objects through custom class definitions and designing interactive graphics programs. Discover the essence of objects, instance variables, methods, and classes, and how they interplay to enhance program organization and functionality.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Course Outcomes of Object Oriented Modeling Design (17630,C604) C604.1 Use object-oriented technologies C604.2 Use Unified Modeling Language C604.3 Perform object-oriented analysis and design C604.4 Explain how the Unified Modeling Language (UML) represents an object-oriented system using a number of modeling views. C604.5 Construct various UML models (including use case diagrams, class diagrams, interaction diagrams, State chart diagrams, activity diagrams, and implementation diagrams) using the appropriate notation. Visit for more Learning Resources Visit for more Learning Resources
1) Object:- An object is a concept, abstraction or thing. An object is an instance of a class. An object is a real time entity e.g. abc, top window are objects
2) Classes: It describes a group of objects with similar properties (attributes) common behavior (operations) common relationships to other objects and common semantics. e.g. a person , a student, are all classes
Object diagram : Object diagram provides a formal graphic notation for modeling objects, classes and their relationships to one another.
Object diagrams are divided into two types class diagram and Instance diagram
Attributes : It is a data value held by the objects in a class. Each attribute has a value for each object instance. Each attribute name is unique within a class. Name, age, weight are the attributes of person object.
Different kind of relationships in UML There are four kinds of relationships in the UML: 1. Dependency: It is a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing.
Graphically, a dependency is represented as a dashed line, and occasionally including a label, as in figure below:
2) Association: It is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association, representing a structural relationship between a whole and its parts.
Graphically, an association is represented as a solid line, occasionally including a label, and often containing other adornments, such as multiplicity and role names, as in figure below:
3. Generalization: it is a specialization / generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent). In this way, the child shares the structure and the behavior of the parent.
Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent, as in figure below:
4. Realization: it is a semantic relationship between classifiers, wherein one classifier classifies a contract that another classifier guarantees to carry out.
Realization relationships encounters in two places: between interfaces and the classes or components that realize them and between use cases and the collaborations that realize them.
Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship, as in figure below:
Things in UML. 1. Class: it is a description of a set of objects that share the same attributes, operations, relationships, and semantics. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations.
2. Interface: it is a collection of operations that specify a service of a class or component. Graphically, an interface is rendered as a circle together with its name.
3. Collaboration: It defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that is bigger than the sum of all the elements.
Graphically, collaboration is rendered as an ellipse with dashed liens, usually including only its name.
4. Use case: It is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor.
Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name.
5. Active class: It a class whose objects own one or more processes or threads and therefore can initiate control activity. An active class is just like a class except that its objects represent elements whose behavior is concurrent with other elements.
Graphically, an active class is rendered just like a class, but with heavy lines, usually including its name, attributes, and operations.
6.Component It is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces.
Notation of component Graphically, a component is represented as a rectangle with tabs, usually including only its name.
7.Node: It is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability. Graphically, a node is rendered as a cube, usually including only its name.
8.Interaction: it is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. An interaction involves a number of other elements, including messages, action sequences, and links.
Graphically, a message is rendered as a directed line, almost always including the name of its operation.
10.State machine: it is a behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events.
Graphically, a state is rendered as a rounded rectangle, usually including its name and its sub states, if any.
10.Package: it is a general purpose mechanism for organizing elements into groups, structural things, behavioral things, and even other grouping things may be placed in a package.
Graphically, a package is rendered as a tabbed folder, usually including only its name and sometimes, its contents.
11.Annotational things: They are the explanatory parts of UML models. These are the comments you may apply to describe, illuminate, and remark about any element in a model. There is one primary kind of annotational thing, called a note.
Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment.
Dynamic modeling: 1. The dynamic model will show how object interact with each other and change their state . 2.The dynamic modeling deals with the events that transpire within the system how an object s variable will change as a result of these events.
3.The dynamic models with the dynamics of the system and illustrates how the changes to object values are controlled. 4. Basically what we are describing here is what the state of an object will be after some event takes place, and this is why the dynamic model is sometimes referred to as a state transition diagram
In the dynamic model each class will have a state transition diagram.
Functional modeling The functional model shows the processes that are performed within an object and how the data changes as it moves between methods. The functional model is a visual display of processes and the path of data within the system.
Functional models are denoted as data flow diagrams (DFDs) with the next concepts. DFD s hierarchically describe processes, due diagrams can be nested. The nesting terminates with simple functions at the lowest level.
The simplicity of DFD notation is one reason why structured analysis techniques are the most widely used. The DFD is a graphical tool that can be very valuable during software requirements analysis.
Architecture Metamodel of UML : 1. Visualizing, specifying, constructing, and documenting a software intensive system demands that the system be viewed from number of perspectives.
1.Design View The design view of a system is structural view of the system. This view primarily supports the functional requirements of the system.
The design view of a system includes the classes, interfaces and collaborations that form the vocabulary of the problem and its solution. Class diagrams and object diagrams form the design view of the system.
2.Process view The dynamic behavior of system can be seen using the process view. This view primarily addresses the performance, scalability, and throughput of the system.
