8 Lecture 1 Introduction to the Class Diagram

ECE 573 1st Edition Exam # 1 Study Guide Lectures: 1 - 8 Lecture 1 Introduction to the Class diagram, Inheritance and Association Class Diagram The final code was supplemented with a diagram describing the relationships between classes. The intermediate classes of the code are related by objects. This is what is represented in a class diagram. The Class diagram basically consists of “a Class name”, “attributes” and “operation”. Given this basic graphical notation, it is possible to show the following kinds of relationships between classes: Inheritance Association Encapsulation Inheritance It is denoted using open triangle between Superclass and its Subclass. The triangle “points" to the superclass, and extends to the subclass (es). Inheritance fulfills the IS-A definitions. A derived class can be treated like a base class object under all circumstances. Association General binary relationships between classes. It is commonly represented as direct or indirect references between classes. Associations are shown by a line in the class diagram, with optional role names and multiplicities. Multiplicities can be i) I..u closed ii) I singleton range iii) 0..* entire nonnegative integer. An association may also be specialized by a particular class. This Association class may provide more attributes to describe the association. Encapsulations Encapsulation is a special kind of association, which is denoted using a diamond and extending line. There are two kinds of encapsulation i.e. Aggregation and Composition. Aggregation is a special form of association representing has-a and part-whole relationship. Distinguishes the whole (aggregate class) from its parts (component class). No relationship in the lifetime of the aggregate and the components (can exist separately). Composition is a stronger form of aggregation. The lifetime of the components is entirely included in the lifetime of the aggregate (a component cannot exist without its aggregate). Dependency Relationship between the entities such that the proper operation of one entity depends on the presence of the other entity, and changes in one entity would affect the other entity. The common form of dependency is the use of relation among classes. Lecture 2 Interaction Modeling There are different levels of abstraction for interaction models: Use Case diagrams, Sequence and Activity diagrams. A use case is a coherent piece of functionality that a system can provide by interacting with actors. A use case brings together all of the behavior relevant to this particular slice of system functionality and behavior. The graphical notation for indicating and summarizing use cases is called a Use Case Diagram. Multiplicity can be stated explicitly or non-explicitly. If not stated explicitly, it is assumed as 1. Sequence Models Sequence models elaborate themes brought out by use cases. They help to formalize the way in which objects expect to receive messages from other objects. Activity Models An activity diagram shows the sequence of steps that make up a complex process, such as an algorithm or workflow. The activity diagram focuses on operations, as opposed to a sequence diagram (which focuses on objects). Lecture 4 Design Patterns A design pattern is a general solution, documented in a format that does not require the specific detail(s) of a particular problem, but relates to “similar” solutions Examples of Design Patterns Model-View-Controller Delegation Target-Action Adapter Iterator Iterator: a pointer with two primary operations. The iterator is usually designed with the collection. Accessing the element currently referred (element access) Incrementing itself to point to the “next” element in the collection (element traversal) Factory pattern The Intent of the factory pattern is that it creates objects without exposing the instantiation logic to the client and refers to the newly created object through a common interface. The implementation is really simple: The client needs a product, but instead of creating it directly using the new operator, it asks the factory object for a new product, providing the information about the type of object it needs. The factory instantiates a new concrete product and then returns to the client the newly created product (casted to abstract product class). The client uses the products as abstract products without being aware about their concrete implementation. A more advanced solution - Factory design pattern with abstractions (Factory Method). Object Pool pattern Object pools (otherwise known as resource pools) are used to manage the object caching. A client with access to an Object pool can avoid creating a new Objects by simply asking the pool for one that has already been instantiated instead. It is desirable to keep all Reusable objects that are not currently in use in the same object pool so that they can be managed by one coherent policy. To achieve this, the Reusable Pool class is designed to be a singleton class. Adapter/Wrapper Design pattern Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. Wrap an existing class with a new interface. Impedance match an old component to a new system Other patterns are: Iterator pattern, Decorator pattern, Interpreter pattern, Visitor pattern. Model View Controller View: Pass events along to controller, update when models change. View represents the visualization of the data that model contains. Controller: Controller acts on both model and view. It controls the data flow into model object and updates the view whenever data changes. It keeps view and model separate. Model: Advise view, whenever the state changes. Update based on messages from controller; notify controller when state changes Lecture 5 Licenses Free Open Source Software Licenses • CopyLeft: Copyleft is a general method for making a program or other work free, and requiring all modified and extended versions of the program to be free as well..

Load more