GRASP Visibility and Design popo GRASP Visibility and

GRASP: Visibility and Design popo

GRASP: Visibility and Design • Visibility is the ability of one object to see or have reference to another. • Visibility Between Objects : • For a sender object to send a message to a receiver object, • The sender must be visible to the receiver • The sender must have some kind of reference or pointer to the receiver object. popo

GRASP: Visibility and Design • There are four common ways that visibility can be achieved from object A to object B: • 1) Attribute visibility B is an attribute of A. • 2) Parameter visibility B is a parameter of a method of A. • 3) Local visibility B is a (non-parameter) local object in a method of A. • 4) Global visibility B is in some way globally visible. popo

GRASP: Visibility and Design • Attribute Visibility • Attribute visibility from A to B exists when B is an attribute of A. • It is a relatively permanent visibility because it persists as long as A and B exists. popo

GRASP: Visibility and Design • Attribute Visibility • For example, a Register instance may have attribute visibility to a Product. Catalog, since it is an attribute of the Register. • This visibility is required because in the enter. Item diagram a Register needs to send the get. Product. Description message to a Product. Catalog: popo

GRASP: Visibility and Design • Attribute Visibility popo

GRASP: Visibility and Design • Parameter Visibility • Parameter visibility from A to B exists when B is passed as a parameter to a method of A. • It is a relatively temporary visibility because it persists only within the scope of the method. • For example, when the make. Line. Item message is sent to a Sale instance, a Product. Description instance is passed as a parameter. • Within the scope of the make. Line. Item method, the Sale has parameter visibility to a Product. Description popo

GRASP: Visibility and Design • Parameter Visibility popo

GRASP: Visibility and Design • Local Visibility • Local visibility from A to B exists when B is declared as a local object within a method of A. • It is a relatively temporary visibility because it persists only within the scope of the method. • Two common ways by which local visibility is achieved are: • Create a new local instance and assign it to a local variable. • Assign the returning object from a method invocation to a local variable. • An example of the second variation (assigning the returning object to a local variable) can be found in the enter. Item method of class Register popo

GRASP: Visibility and Design • Local Visibility • An example of the second variation (assigning the returning object to a local variable) can be found in the enter. Item method of class Register popo

GRASP: Visibility and Design • Global Visibility • Global visibility from A to B exists when B is global to A. • It is a relatively permanent visibility because it persists as long as A and B exists. • It is the least common form of visibility in objectoriented systems. • One way to achieve global visibility is to assign an instance to a global variable, • which is possible in some languages, such as C++, but not others, such as Java popo

Creating Design Class Diagrams (DCDs) popo

Creating Design Class Diagrams (DCDs) • DCDs follows after the creation of interaction diagrams, or created in parallel. • Many classes, method names and relationships may be sketched out very early in design to the drawing of interaction diagrams. • After the interaction diagram update the DCDs, then extend the interaction diagrams some more, and so on. • These class diagrams may be used as, more graphical notation in order to record responsibilities and collaborators. popo

Creating Design Class Diagrams (DCDs) • Sample DCD popo

• • • Creating Design Class Diagrams (DCDs) DCD and UP Terminology A design class diagram (DCD) illustrates the specifications for software classes and interfaces in an application. Typical information includes: Classes, associations and attributes Interfaces, with their operations and constants Methods Attribute type information Navigability Dependencies DCDs show definitions for software classes rather than real-world concepts. popo

Creating Design Class Diagrams (DCDs) • DCD and UP Terminology • The UP does not specifically define an artifact called a "design class diagram. " • The UP defines the Design Model, which contains several diagram types, including • interaction, package, and class diagrams. • The class diagrams in the UP Design Model contain "design classes" in UP terms. popo

Creating Design Class Diagrams (DCDs) • Inception phase —The Design Model and DCDs will not usually be started until elaboration • Because it involves detailed design decisions during inception. • Elaboration Phase—During this phase, DCDs will accompany the use-case realization interaction diagrams; • They may be created for the most architecturally significant classes of the design. • Construction Phase—DCDs will continue to be generate d from the source code as an aid in visualizing the static structure of the system. popo

Creating Design Class Diagrams (DCDs) • Assignment : • 1) Creating a Next. Gen POS DCD • 2) Test Driven Development and Refactoring • Submitted on 16/8/2016, 9: 00 AM popo