the purpose of solving a software problems. Some Characteristics are as follows: › Objects are abstractions of the real-world or system entities and manage themselves. › System functionality is expressed in terms of object services. › Communication between objects is through message passing. › The objects may be distributed and may execute sequentially or in parallel. To design classes and their attributes, methods, associations, structure. › The static UML class diagram is redefined and completed by adding details. › Attributes are refined. › Protocols and methods are designed by utilizing a UML activity diagram to represent the methods algorithm. › If required, redefine associations between classes, and refine class hierarchy and design with inheritance. › Iterate and refine again. Design the access layer. › Create mirror classes i.e., for every business class identified and created, create one access class. Simplify classes and their relationships. › The main objective here is to eliminate redundant classes and structures. › Redundant Classes: Programmers should remember to not put two classes that perform similar translate requests and translate results activities. They should simply select one and eliminate the other. › Method Classes: Revisit the classes that consist of only one or two methods, to see if they can be eliminated or combined with the existing classes. Iterate and refine again. Design the view layer classes. › Design the macro level user interface, while identifying the view layer objects. › Design the micro level user interface. › Test usability and user satisfaction. › Iterate and refine. At the end of the process, iterate the whole design. Re-apply the design axioms, and if required repeat the preceding steps again. cohesion refers to the degree to which the elements inside a module belong together. a class with high cohesion would be one where all methods and class level are used together to accomplish a specific task. modules with high cohesion tend to be preferable in software design There are two types of Cohesions: › Low Cohesion › High Cohesion coupling indicates to how closely two modules interact or how interdependent they are. how much one module knows about the inner workings or inner elements of another one, i.e. how much knowledge it has of the other module. the system has low coupling, it is a sign of well structured computed sys & a great design. There are two types of Coupling: › Tight Coupling › Loose Coupling Tight Coupling: › Tight coupling occurs when one entity depends implicitly on another › Example: Object instances are tightly coupled to their classes because they share both public and protected information. A change in the class definition affects every instance of the class. › Shared variables or control information exchange lead to tight coupling Loose Coupling › Loose coupling means component changes are unlikely to affect other components › Loose coupling can be achieved by state decentralization (as in objects) and component communication via parameters or message passing › Loose coupling occurs when one entity references another indirectly through a public interface › Example: Client/server relationship using HTTP › Loose coupling usually increases reusability and decreases maintenance costs Association › Very weak coupling (which is good), but coveys little information (so not very useful) Using › Client/server model › Provides very loose coupling › Good-to-excellent reusability Generalization › Strong, but often useful form of coupling Data Coupling › Data is passed from one module to another using arguments Stamp Coupling › More data than necessary is passed via arguments e.g. pass the whole record instead of just the field being changed Control Coupling › A flag is passed from one module to another affecting the functionality of the second module › modules are not independent and so reuse is limited › violates principle of ‘information hiding’ › calling module must ‘know’ how the called module works + Public ‐ Private # Protected ~ Package A Stereotype is a mechanism use to categorize classes Primary class stereotypes in UML Provide the interface to a user or another system. Handles communication between system surroundings and the inside of the system › User interface classes › System interface classes › Device interface classes Fundamental building block which perform internal tasks Represent real world entity They correspond to database table
Objects that mediate between
boundaries and entities. Typically one control class per use case Association Aggregation/Composition Generalization Dependency Link between classes Type of relationship The number of objects from one class that relate with a single object in an associated class 1 Exactly one 0..* Zero or more 1..* One or more 0..1 Zero or one 5..8 Specific Range (5,6,7 or 8) Multiplicity Aggregation And Composition Referential integrity refers to the accuracy and consistency of data within a relationship. In relationships, data is linked between two or more tables. This is achieved by having the foreign key reference a primary key value whenever a foreign key value is used it must reference a valid, existing primary key in the parent table. So referential integrity will prevent users from: › Adding records to a related table if there is no associated record in the primary table. › Changing values in a primary table that result in orphaned records in a related table. › Deleting records from a primary table if there are matching related records. if we delete record number 15 in a primary table, we need to be sure that there’s no foreign key in any related table with the value of 15. We should only be able to delete a primary key if there are no associated records. Otherwise, we would end up with an orphaned record.