WEEK4

Week 4’s slides start off with an introduction to UML interaction diagrams, diagrams which show how objects interact via messages. The first UML interaction diagram discussed was communication diagrams. Communication diagrams demonstrate object interactions in a graph or network format. The next UML interaction diagram spoken of was the sequence diagrams which are diagrams that explain interactions in a kind of fence format. When it comes to these types of diagrams the set of all operation contracts defines system behavior. It is also said, in the slides, that you’ll need to create an interaction diagram for each operation contract.
The next section of slides goes in detail about designing objects with responsibilities and methods. Before I go into detail about the responsibilities and methods, it’s important to first understand that the focus of object design is to: * Identify classes and objects. * Decide what methods belong. * Where and how these objects should interact.
See, responsibilities are assigned to classes during object design. There are two types of responsibilities, the “doing” and the “knowing.” The “doing” is known for doing something itself; it initiates the action in other objects and controls/coordinates the activities in other objects. The “knowing” is more about the related objects, private encapsulated data and things it can derive/calculate. Responsibilities related to “knowing” often are inferable from the Domain Model because of the attributes and associations it illustrates. That being said, a responsibility is not the same thing as a method, even though methods are applied to satisfy responsibilities. Methods are branded to either act alone or join forces with other methods and objects. Ensuing in the slides, we find refactoring. Refactoring is a well-ordered technique for restructuring an existing body of code, by varying its internal structure without changing its external behavior. This technique is a controlled and disciplined type of procedure which means it should be done in small steps and testing should be redone after each step. When it comes to its goals, it’s real similar to the general goals of good programming: eliminate duplicate code, increase clarity, make long methods shorter, get rid of the use of hard-coded literals, etc… These goals are what make properly refactored code (short, tight, clear and without duplication). Certain circumstances transpire repeatedly enough in refactoring to be considered as predictable patterns. Examples: extract method, extract constant, collapse hierarchy, substitute algorithm, etc… Just to name a few. GRASP is the next topic discussed in this week’s slideshow. The General Responsibility Assignment Software Patterns comprises of guidelines for assigning responsibility to classes and objects in object-oriented design. The different patterns and principles used in GRASP are: * Controller: assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. Also the controller object (a non-user interface object) is responsible for getting or managing a system event. * Creation: one of the most common activities in an object-oriented system. * High Cohesion: an evaluative pattern that attempts to keep objects properly focused, manageable and comprehensible. * Indirection: supports low coupling between two elements by conveying the responsibility of mediation between them to an intermediary object. * Information Expert: used to regulate where to delegate responsibilities. * Low Coupling: orders how to assign responsibilities to support the following lower dependency between the classes, higher reuse potential and change in one class having lower impact on other classes. * Polymorphism: accountability of outlining the variation of behaviors based on type is assigned to the types for which this variation materializes. * Protected Variations: defends elements from the variations on other by draping the focus of uncertainty with an interface and using polymorphism to create various implementations of this interface. * Pure Fabrication: a class that does not embody a concept in the problem domain, particularly made up to accomplish low coupling, high cohesion, and the reuse potential thereof derived.
The next subject is visibility which deals with the capability of an object to “see” or have reference to another object. Visibility between objects is imperative for the reason that for a sender object to send a message to a receiver object, the receiver must be visible to the sender. The four ways visibility can be attained from object A to object B: attribute (where B is an attribute of A), parameter (where B is a parameter of a method of A), local (where B is a non-parameter local object in a method of A), and global (where B is in some way globally visible).
DCD, design class diagram, is what’s up next in the slides. Class diagrams are used for many different purposes. This diagram generally consists of interfaces, classes, associations and collaborations. It’s design to illustrate the object-oriented view of a system. UML design class diagrams (DCD) display software class definitions. They are founded on the collaboration diagram. Attribute visibility is shown for permanent connections while classes are shown with their simple attributes and methods listed. When it comes to syntax, it’s easy: CLASS NAME | ATTRIBUTES | METHODS |
The usual information you’ll find in a DCD consist of: classes, associations/attributes, interfaces, methods, navigability and dependencies. The DCD depends upon the Domain Model and interaction diagrams. These design class diagrams depend on the Domain Model and interaction diagrams. When it comes to building one of these diagrams, first you’ll need to find all the classes partaking in the software solution by evaluating the interaction diagrams; once that is completed you’ll then begin drawing them in a class diagram. It’s imperative when building a class diagram to copy the attributes from the associated concepts in the Domain Model and add the method names by again evaluating the interaction diagrams. Once all of that is completed you’ll need to then add type information to the attributes and methods. As you can see the object orientation of a system is clearly indicated by a class diagram.
Creating class definitions from these DCDs: * Class or interface name * Super classes * Operations signatures * Attributes
Lastly, this week’s slides go in example-based detail about the phases to mapping designs to code; Starting with the first being defining a class with methods and simple attributes. Second adding reference attributes, third, reference attributes and role names and fourth creating methods from interaction diagrams.