Rational Unified Process (RUP): The Rational Unified Process is a Software Engineering Process.

It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. The Rational Unified Process is a process product, developed and maintained by Rational Software. The development teams for the Rational Unified Process are working closely with customers, partners, Rational's product groups as well as Rational's consultant organization, to ensure that the process is continuously updated and improved upon to reflect recent experiences and evolving and proven best practices.

Figure: Rational Unified Process

FURPS+ model (Grady 1992): FURPS is a checklist for requirements: Functional (features, capabilities, security) Usability (human factors, help, documentation) Reliability (frequency of failure, recoverability, predictability) Performance (response time, throughput, accuracy, availability, resource usage) Supportability (adaptability, maintainability, internationalization, configurability) And dont forget. Implementation (resource limitation, language and tools, hardware) Interface (constraints posed by interfacing with external systems) Operations (system management in its operational setting) Packaging (for example, a physical box) Legal (licensing)

GRASP Patterns Larman introduces a set of basic patterns that he calls GRASP: General Responsibility Assignment Software Pattern Five GRASP Patterns: a) b) c) d) e) Information Expert Creator High Cohesion Low Coupling Controller

a) Information Expert Problem: What is a general principle of assigning responsibilities to objects? Solution: Assign a responsibility to the information expertthe class that has the information necessary to fulfill the responsibility. This is general principle and probably the most used of any GRASP pattern. This generally is key to lose coupling and high cohesion, but not always so. Imagine a case where it is better to hand off data in order to preserve a large functional divide and aid cohesiveness. We are implicitly talking about info held by a software object, but if there are not relevant software classes, try the domain model.

b) Creator Problem: Who should be responsible for creating a new instance of some class? If done poorly, this choice can affect coupling, clarity, encapsulation, and reusability. Solution: Assign class B the responsibility to create an instance of class A if one of the below is true (the more the better). If more than one option applies, usually prefer a class B which aggregates or contains A. B contains or is composed of A. B records A. B closely uses A. B has the initializing data for A that will be passed to A when it is created. Thus B is an Expert with respect to creating A. This pattern generally avoids adding coupling to a design.

c) High Cohesion Problem: How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling? Solution: Assign a responsibility so that cohesion remains high. Use this to evaluate alternatives. Cohesion refers to the functional cohesion between elements (classes, subsystems, systems, etc.), which is a measure of how strongly focused the responsibilities of an element are. Very similar to Low Coupling Often related (but not always) Should be considered in every design decision. Lower cohesion almost always means: An element more difficult to understand, maintain, or reuse An element more likely to be affected by change Low cohesion suggests that more delegation should be used.

d) Low Coupling Problem: How to support low dependency, low change impact, and increased reuse? Solution: Assign a responsibility so that coupling remains low. Use this principle to evaluate alternatives. Coupling refers to any type of tangible dependency between elementsclasses, subsystems, systems, etc. - and are referenced by its degree: Weak (low) is good. Strong (high) is bad. Higher coupling can lead to: More difficulty in understanding Changes propagating excessively More obstacles to code reuse Lower coupling often goes handinhand with higher cohesion

e) Controller Problem: What first object beyond the UI layer receives and coordinates (controls) a system operation? Solution: Assign the responsibility to one of the following types of classes: Faade Controller: represents the overall system, a root object, or a device that the software is running Use case or session controller: represents a use case scenario within which a system event occurs (e.g., add an address book entry) The class would typically be named <UseCaseName> Handler, <UseCaseName> Coordinator, or <UseCaseName> Session A controller attempts to coordinate the work without doing too much of it itself (again, guided by the degrees of coupling and cohesion) The keyword is delegation. An easy example of this is that UI objects shouldnt perform business logic; there are other classes for that. The controller in the ModelViewController (MVC) architecture is effectively the same thing. This, or its variation ModelViewPresenter, is frequently used in web applications

CRC Cards: CRC stands for Class-Responsibility Responsibility-Collaboration. Collaboration. It defines a brainstorming technique that is quite popular among object-oriented object oriented developers. Developers use it during analysis activities to help identify classes and the scope of each class. It is also used extensively during design to help identify responsibilities of the class and the sets of classes that collaborate for a particular use case.

A CRC card is simply a 3x5 or 4x6 index card with lines lines that partition it into three areas areas class name, responsibility, and collaboration classes. The card is partially filled out. Along the top of the card is the name of the class. The left partition lists the responsibilities for objects in this class. Responsibilities esponsibilities include information that the class maintains and actions that the class carries out in support of some use case. The right partition lists other classes with which this class collaborates in support of a particular use case. The information within parentheses is return information from the collaborating class to the main class. On the back of the card, you have the option of listing important attributes that are required for a particular use case.

Figure: CRC Card