OOAD

                                   REQUIREMENTS

Requirements:

• To deisign a Software , The requirements plays major role. If the requirements are statisfied then that sotware becomes great software.
• In designing a Software , The additional options may require which are not specified by the customer need to be considered.

Test Drive:

• Once Software design is completed , that has to under go Test drive. At this stage
  customers views is considered as mandatory and also get more informations relatated to modifications , updatations etc.
• Make a list of the customers requirements as well as modifications.

Use case:

Def:- A use case is a methodology used in system analysis to identify, clarify,

and organize system requirements.

The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal.

Use case are meant to be understand by you , your mangers ,your customers and other programmers.

A good use case clearly and accurately signifies a system design.

It has 3 basic parts.

             a)Clear value

              b)Start and Stop
              c)External Initiator

1. Every use case must have a Clear value to the system in order to satisify the customer
2. Every use case must have a definite Starting and Stoping point. Something hast start the processs and there must be a condition that inidicates the process is end.
3. Every use case is started off by an External initiator, outside the system.
   Note:-Use cases are certainly a good start towards wrting a good software.

Main path(Complete path):

Def:A path through a use case from the first step to last, is called Main path.

Alternate Path:

Def:Alternate paths are the additional steps to main path. A alternate path is one or more steps that a use case has that are optional or provided alternate ways to work through the use case.

Most use cases have several different scenarios but always share with same user goal

Note: Good use of use case ,requirements ,main paths and alternate paths leads to the software.

Requirements Changes:-

The requirement changes are not predictable ,so the software design should be flexiable and it should be ready to incorporate the new requirements and modifications as on software grows.

Analysis

There are two cases of Software deployment.

1)Perfect world.

2)Real world.

• While we design a Software , the real world things are not considered, So the Problems comes and need to solve the problems of software Desing with Analysis in the real world.
• Analysis helps to ensure and slove the problems in the real world context.
• The aim of Analysis is to figure out the potentail requirements of Software design
• Analysis and use case helps software designers to go in the right path and make it to work in the real world context.

Textual Analysis:

Textual analysis helps us to translate use case into code levels classes , attributes and operations.

Select a good nouns to present a class. To do this list out all the possible nouns for a class. Make good analysis ,which noun will fit the class name.

Verbs are part of use case/class. This verbs are used for naming methods of a class.

Class diagrams:-

A class diagram is an illustration of the relationships and source code dependencies among classes in the Unified Modeling Language .

The purpose of a class diagram is to depict the classes within a model. In an object oriented application,classes have attributes (member variables), operations (member functions) and relation-ships with other classes.

Class diagrams give an esay way to show your system and its code contructs.

It gives a lot of informations such as constructors,some type of infromations and the purpose of operations on classes.

Attributes:

An attritbute is a property of a class. The attributes in class digram usually map to the member variables to class.

Note:Based on the behaviour and each use case , a class has to be defined. Behaviour is the Generic of a class.

DESIGN

Design features:

• Design has purpose.
  They describe how something will work (in a context).
• Designs have enough information so that someone can implement them.
• There are different styles of design.
  Like different types of house architectures.
• Designs can be expressed at different levels of detail.
  A dog house needs less detail than a skyscraper.

Three steps of Great software:

• Make sure the software does what the customes wants
• Apply good object-oriented principles
• Strive for a maintainable, reusable design

Abstract Class:

Abstract class are the place holders for actual implementation classes.

Abstract class defines the behaviour and sub classes implement that behaviour.

Note:If we find the same behaviour at two or more places,it better to abstract that behaviour into a class called abstract class and its extent behaviour to subclass.

UML Definitions:

The Unified Modeling Language (UML) is a graphical language for visualizing,
specifying, constructing, and documenting the artifacts of a software-intensive system.
The UML offers a standard way to write a system's blueprints, including conceptual
things such as business processes and system functions as well as concrete things such
as programming language statements, database schemas, and reusable software
components."

Case diagrams: It represent the functions of a system from the user's point of view.

Actors :

Use Cases are typically related to 'actors', which are human or machine entities that use or interact with the system to perform a piece of meaningful work that helps them to achieve a goal. The set of Use Cases an actor has access to defines their overall role in the system and the scope of their action.

Class digrams:

A class diagram is a diagram showing a collection of classes and interfaces, along with the collaborations and relationships among classes and interfaces.

Inheritance:

The inheritance relationship in UML is depicted by a peculiar triangular arrowhead. This arrowhead, that looks rather like a slice of pizza, points to the base class. One or more lines proceed from the base of the arrowhead connecting it to the derived classes.

Note: usally Is -A refers to inheritance. But not always.

Example: 1. “A sword Is -A weapon ,so sword should extend weapon”. 2.“square Is-A rectangle , so square should extend rectangle”.

Use inheritance when one object behaves like another, rather than 
when the Is-A relationship applies.
Here the beviour of square is different from rectangle.

Association:Association defines the relationship between two or more classes in the System. These generally relates to the one object having instance or reference of another object inside it.

                             Class student

                               {

                               //methods

                               };

                               class college

			{
  			private:
    				student s;
			};

Multiplicity:Multiplicity indicates the no of instance of one class is linked to one instance of another class.

Aggregation: It is special form of Association and means that one thing is made up(part in) of another thing . Aggregation is a special type of ‘has-a’ relationship between classes where one of the two participating classes is part of other one.

It is more restrictive form of “part of” association.

Aggregation represents the set of Main Classes that are dependent on Sub- Classes, the Main class cannot exists without Sub-Class but the Sub-Class can exists without the Main Class.

Example:

class car //main class

{

Engine eng;

} ;

class Engine //sub class

{

attributes:

operatiosn:

}

In thsi example car is main class which depends on sub class becase car is made of Engine.

But engine can be care or bike which doesnot depend Main class.

In UML ,it is represented with arrow ended diamond symbol.

Composition:Composition represents the set of Main Classes that are dependent on Sub- Classes, the Main class cannot exists without Sub-Class and the Sub-Class cannot exists without the Main Class. The Sub-Class can represent only one composite relation with the Main class.

It is stricter form of aggregation.

A strong form of aggregation in which the “whole” is completely responsible for its parts and each “part” object is only associated to the one “whole” object

Composition relationships are a strong form of Aggregation.

Composition is specified by an filled solid diamond nearest the Main Class.

Note:Has-A refers to compsotion or aggergation.

Solving BIG PROBLEMS

1. Big problems can solved by breaking it into small functionality modules and slove
   this modules individually.
2. Use encapsulation to slove big problems because it allows you , smaller functionalities to be bind together with its data and member functions. Its helps for more flexible and easier to change. Use this concepts as much possible.
3. Coding to an interface rather than an implementation makes your software more flexible.
4. Analysis helps you ensure your system works in the real world context.
5. The best way to get good requirements is to undesrstand what a system supposed to do.
6. Analysis plays a vital role to slove the big problems.
7. Great software is one , that has to change in easy manner , extend the requirements, should be flexible and does what customers want to do.
8. Features/Requirements and use cases are the good starting point for software design.
9. Start the flow of software design with getting informations ->features->requirements.
10. A feature is the high level desciption of something a system needs. Starting with features of system is helpful in big projects. Any single feature can result mutliple requirements.
11. Get the features form the customers and figure out the requirements you need to be implemented those features.
12. Use case diagrams are the blue prints for the system design.

Domain analysis:

It is process of identifying, collecting , organizing and representing the relevant information of a domain. Based upon the study of existing systems and their development histories, knowledge captured from the domain experts, underlying theory and emerging technology within domain.

Domain analysis is representing a system in language that the customer

will understand. Domain analysis lets us check our designs and still speak to customer's language.

Model view controller pattern:

The Model-View-Controller (MVC) pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes

• Model. The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
  

• View. The view manages the display of information.
  

• Controller. The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate.
  

Typical example.
Input --> Processing --> Output
Controller --> Model --> View Arichitecture

  Architecture

Def: Architecture is the organizational structure of a system including its decomposition into parts ,their connectivity, interaction mechanism and the guiding principles and decesions that are use in the design of a system.

Architecture is your design structure and highlights the most important parts of your application and the relationships between those parts.

• It outlooks the structure of application or system
• It identifies the key components of the system
• It gathers the relationship between the different parts of the system.

Note: The architecture is the blue print for ths system. Architecture reduces the risk of system design.

Software Blue prints:

1. Requiremenst(Features ) ,especially use cases
2. UML diagrams

• use cases
• classes
• package/component
• sequence
• others

3. Interfaces
4. key classes with methods
5. prototypes
6. Patterns
7. etc.

Three Qs of architecture:

1.Is it part of the essence of the system?

If you can’t build the system without it, it’s essential

Do you really understand this feature

2. What the heck does it mean?

The essence of a system is what that system is at its most basic level.

3.How can I implement it?

Lack of knowledge

New or non-existent technology

Use case:

In software engineering, a use case is a technique for capturing the potential requirements of a new system or software change.

use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal.

Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert.

Scenario:

A scenario is a brief narrative, or story, that describes the hypothetical use of a system. In one or more paragraphs, a scenario:

• Tells who is using the system and what they are trying to accomplish.
  

• Provides a realistic, fictional account of a user's constraints: when and where they are working, why they are using the system, and what they need the system to do for them.
  

• Describes any relevant aspects of the context in which the user is working with the system, including what information the user has on hand when beginning to use the system.
  

• Gives the user a fictional name, but it also identifies the user's role, such as student, faculty member, staff, or general public.
  

• Indicates what the user regards as a successful outcome of using the system.
  
• Scenarios exhibit the key features.
  

A scenario is a sequence of steps describing an interaction between a user and a system.

A scenario can be the one path through use case.

Scenario diagrams - Sequence diagrams to depict the workflow; similar to Scenarios but graphically portrayed.

DESIGN PRINCIPLES

Design princilpe is a basic tool or technique that can be applied to designining or writing a code to make the code more mintainable, flexiable or extendable.

OO design principles helps us the sytem to maintainable, flexiable and extendable.

The OO principles are a)Encapsulate what that varies.

b)Code to a interface rather than implementation.

c)Each class in an application should have one reason to change.

d)class should be based on behaviour and functionality.

Open closed principle(OCP):

Every class should be open for extension and close for modifications.

OCP is about for flexbility and it is beyond the inheritance.

It is combination of encapsulation and abstraction.

Don't repeat yourself(DRY):

Avoid duplicating the code by abstracting out things that are common and place those things in single location.

DRY is about to have each piece of information and behaviour in a system

at single, sensible place.

Single resposibility principle(SRP):

Every object in a system should have single responsibility , and all the object's services should be focused on carrying out that responsibility.

[or]

Each class or object should have only one reason for it to change.

• Each responsibility should be a separate class, because each responsibility is an axis of change.

• A class should have one, and only one, reason to change.
  
• CRC (Class resposibility collaborator) cards help to implement the SRP.
  

Liskov substitution priniciple(LSP):

sub types must be substituable for their base types.

If T is class and S is a sub class of T, then every where you can use an instance of T in your program , you must be able to use an istance of S.

Delegation:

Delegation is when you hand over the responsibility for a particular task to another class or method.

• Delegate is the reponsibility for a task to another class or object.
• Use when you want to use another class's functionality without changing it or when you can encapsulate varibility in a supporting task.
  
• Prefer delegation to inheritance.

Composition:
Composition allows you to use the behavior from a family of other classes and to change the behavior at run time.

Composition lets you choose behavior from a family of behaviors ,often via several implementations of interface

Example: Pizza is the best example which composed a lot of ingredients ,we can swap out the ingredients without affecting the slice of pizza.
Note:when a object is composed of other objects ,and owning object is destroyed , the objects which are part of the composition also get destoryed.
Aggregation: It is when one class is used as part of another class, but still exits outside of that another class.

Aggreation allows you to use the behaviour from another class without limiting the life time of those behaviors.

All the above three OO techniques allow you to resue the behaviour without violating the LSP .

Note: If you favour delegation, composition and aggregation over inheritance , your software will usually be more flexiable , and easier to maintain, extend and reuse.

ITERATING AND TESTING

Great software should be written in iterative manner.

1. There are 3 development approaches a) Feature driven Development

b)Use case driven Development.

c)Test driven Development.

Feature driven Development:

In this type of development , you need to pick up a specific feature in your applications, and plan , analyze and develop that feature to completion .

Feature driven development is more granular.

Charcteristics:

• Allows you to show customer , working code faster.
• It is functionality Driven , It doesn't allow any feature to forget.
• This works well, when different features that don't have interconnected whole part of it.

Use case driven Development:
In this type of development ,you need to pick up a scenario through a use case
and write code to support the complete scenario through the use case.
Use case driven development is more “ Big picture”.
Charcteristics:

• Allows you customer to show the bigger pieces of functionslity at each stage of development.
  
• It is very user centric. You'll code for all the different ways a user can use.
  
• This works well when your applications consits lot of processes and scenarios rather than individual functionality units.
  

Test driven development:

1. In this you need to write test scenarios for a piece of functionality before writing code for that functionality. Then you write software to pass all the tests.
2. Tests allows you to make sure your software doesnot have any bugs.
3. Good software development usually incroporates all of above development models at different stages of development cycle.
4. Test driven development focuses on getting the behaviour of your class in right way.
5. Good softwares are built iteratively. Design, analyze and then iterate again ,working on smaller and smalller parts of your applications.
6. Each time you iterate, reevalute your design desions and don't be afraid to change something if it makes sense of your design.
7. Design Decision are always Tradeoff.
8. If progrmmar emphasis on commonality, theres is chance of avoid DRY principle.
9. If programmar emphasis on variablity, Encapsualtions comes into picture and leads to the flexible design of the software.

Test case principles:

• Each test case should have an Id and name.
  
• Each test case should have an specific thing that it tests.
  
• Each test case sould have an input you supply.
  
• Each test case should have an out that you expect.
  
• Most test cases have starting state.
  

Programing Practices:
programming by contract sets an agreement about how your software behaves that you and users of your software agree to abide by.

Programming by contract is really all about trust.

When you are programming by contract ,you are working with client code agree on how you handle problem situations.

Defensive programing does not trust others softwares and does extensive error and data checking to ensure other software doesnot give you bad or unsafe informations.

When you are programming defensively ,your making sure that client gets safe response, no matter what the clients wants to happen.

OOAD LIFECYCLE

Feature List: Figure out what your application supposed to do at high level.

Features reflect functionality.

Use case diagrams:Figure out what the external forces involved in the big processes/system design.

Use case diagrams let you start thinking about how your software will be used, without geting unnecessary details.

Use case reflect usage of the system.

Note:Feature and use case work together but they are not same.

Break up the problem: Break up the application into modules of functionality and decide the order in which need to tackle each module.
Requiremnets: Figure out the individual requirements for each module and make sure that fit in the big picture.
Domain analysis: Figure out the use cases that maps to the objects in your application and make sure the customer and designer in the right path.
Preliminary design: Identify the objects in an applications and define the relationship between the objects and apply the principles and patterns.
Implementation: Now write the code for each featutre or use case and make sure that it will work and test at each level.
Encapsulation: It is combination of data and behaviour, information hiding ,seperation of an interface from implementation.
Refactoring:Rectoring is the process of modifying the structure of your code without modifying its behaviour. Refactoring is done to increase the cleaness ,flexibility and extensiabilityof your code and usually related to a specfic improvements in your design.