OODE Introduction - Revision history

Suhridk at 15:58, 3 January 2012

2012-01-03T15:58:38Z

Suhridk: /* Quality in OO Systems */

2012-01-03T15:54:29Z

Quality in OO Systems

Suhridk: /* Quality in OO Systems */

2012-01-03T15:47:15Z

Quality in OO Systems

Suhridk: /* UML */

2012-01-03T15:31:34Z

UML

Suhridk: /* What is OO Development */

2012-01-03T15:09:53Z

What is OO Development

Suhridk: /* What is OO Development */

2012-01-03T15:08:49Z

What is OO Development

Suhridk: /* Why OO */

2012-01-03T14:46:41Z

Why OO

Suhridk at 12:34, 30 October 2011

2011-10-30T12:34:40Z

Suhridk: Created page with " Category:OODE"

2011-10-30T12:33:21Z

Created page with " Category:OODE"

New page

[[Category:OODE]]

@@ Line 1: / Line 1: @@
-= Introduction =
+= Why OO =
 * Modern systems are large and complex - lots of interconnected components, distributed and heterogeneous.
@@ Line 13: / Line 11: @@
 ** Lots of interacting parts, lots of complexity. Requirements keep changing.
-== When to use OO ==
+= When to use OO =
 * For the systems where the user is in control e.g. decision support systems, CRM's, enterprise systems. OO makes it easier to model such systems.
 * Systems where long term extensibility is important. Again OO's concepts make it easier to incorporate extensibility.
-== What is OO Development ==
+= What is OO Development =
 * Quite simply, the use of classes and objects in developing software and systems.
@@ Line 26: / Line 24: @@
 * OO Development implies using classes and objects '''''throughout''''' the construction process - requirements analysis, design, coding and testing.
-== Development Methods ==
+= Development Methods =
 * Waterfall - doesnt work for large systems
@@ Line 37: / Line 35: @@
 ** UML is a popular modeling language.
-== Modeling ==
+= Modeling =
 * Create models at each phase, requirements, design etc.
@@ Line 43: / Line 41: @@
 * Hence models are easier to change - but is difficult to keep the model in sync with the actual system.
-== UML ==
+= UML =
 * A visual language for describing many aspects of system design and requirements.
@@ Line 53: / Line 51: @@
 * The graphical notation consists of various diagrams such as class, communication, state charts, use case diagrams etc.
-== Agile Development ==
+= Agile Development =
 * A class of development methods that emphasize developments as a series of small steps.
@@ Line 61: / Line 59: @@
 * Many agile methods: XP, SCRUM, DSDM.
-== Software Quality ==
+= Software Quality =
 * One of the primary goals of SE is to produce quality software.
 * How can quality be measured ?
@@ Line 68: / Line 66: @@
 * So, again '''why OO''' ? OO is ''one'' technique improve internal construction and design of a system to improve software quality.
-=== Quality in OO Systems ===
+= Quality in OO Systems =
 * High quality OO systems will be non-monolithic - high cohesion, low coupling.
 * Heuristics exist to build high quality OO systems:
-* Direct Mapping Rule
-** The class structure in the system must relate (clear mapping) to the structure in the model.
+== Direct Mapping Rule==
-** The development is seamless, the concepts of class and objects are all pervasive.
+* The class structure in the system must relate (clear mapping) to the structure in the model.
-** But in practice, difficult to describe customer requirements, which tend to be goal/event based using classes/objects.
+* The development is seamless, the concepts of class and objects are all pervasive.
-** So we need modeling things such as use cases and interactions.
+* But in practice, difficult to describe customer requirements, which tend to be goal/event based using classes/objects.
-** Consequently using an OO ''modeling'' language with an OO ''programming'' language is helpful.
+* So we need modeling things such as use cases and interactions.
-** OO model language with non OO programming language is problematic.
+* Consequently using an OO ''modeling'' language with an OO ''programming'' language is helpful.
-* Coherent Interfaces Rule
+* OO model language with non OO programming language is problematic.
-** Each class has an interface which declare the services the instances of the classes provide.
-** A class and its interfaces should represent a coherent view of some concept in the problem or solution domain.
+== Coherent Interfaces Rule ==
-** That abstraction should encapsulate the information about a particular concept: e.g. Bank Account, Flight Plan, Player. This relates to high cohesion.
+* Each class has an interface which declare the services the instances of the classes provide.
-* Small Interfaces Rule
+* A class and its interfaces should represent a coherent view of some concept in the problem or solution domain.
-** When two objects communicate, they should exchange as little information as possible. This relates to weak or low coupling.
+* That abstraction should encapsulate the information about a particular concept: e.g. Bank Account, Flight Plan, Player. This relates to high cohesion.
-* Explicit Interfaces Rule
+== Small Interfaces Rule ==
-** When two objects are communicating, this must be obvious from their class definitions. The conversations need to be clearly visible - to facilitate understanding.
+* When two objects communicate, they should exchange as little information as possible. This relates to weak or low coupling.
-* Information Hiding Rule
-** AKA Encapsulation.  Data must be hidden, kept private so that client objects are kept independent of implementation.
+== Explicit Interfaces Rule ==
-** Only that information must be exposed which is necessary to use the services provided by each object. The interface of a class is public, everything else must be hidden.
+* When two objects are communicating, this must be obvious from their class definitions. The conversations need to be clearly visible - to facilitate understanding.
-* Open-Closed principle
-** Class should be open i.e. easily extensible and it should be closed to allow usage (well-encapsulated).
+== Information Hiding Rule ==
 [[Category:OODE]]

@@ Line 78: / Line 78: @@
 ** Consequently using an OO ''modeling'' language with an OO ''programming'' language is helpful.
 ** OO model language with non OO programming language is problematic.
 * Coherent Interfaces Rule
-** A class and its interfaces should represent a coherent view of some concept in the problem or solution domain. e.g. Bank Account, Flight Plan, Player. This relates to high cohesion.
+** Each class has an interface which declare the services the instances of the classes provide.
 * Small Interfaces Rule
 ** When two objects communicate, they should exchange as little information as possible. This relates to weak or low coupling.
@@ Line 87: / Line 88: @@
 * Information Hiding Rule
 ** AKA Encapsulation.  Data must be hidden, kept private so that client objects are kept independent of implementation.
 * Open-Closed principle
 ** Class should be open i.e. easily extensible and it should be closed to allow usage (well-encapsulated).
 [[Category:OODE]]

@@ Line 73: / Line 73: @@
 * Direct Mapping Rule
 ** The class structure in the system must relate (clear mapping) to the structure in the model.
 ** But in practice, difficult to describe customer requirements, which tend to be goal/event based using classes/objects.
 ** So we need modeling things such as use cases and interactions.

@@ Line 52: / Line 52: @@
 # A metamodel: which specifies the validity of models.
 * The graphical notation consists of various diagrams such as class, communication, state charts, use case diagrams etc.
 == Software Quality ==

@@ Line 21: / Line 21: @@
 * Quite simply, the use of classes and objects in developing software and systems.
-* Classes represent recurring, reusable, extensible concepts that provide services. A class is an informational abstraction, representing a concept, some information, a facility as a type that can be instantiated
+* Classes represent recurring, reusable, extensible concepts that provide services. '''A class is an informational abstraction, representing a concept, some information, a facility as a type that can be instantiated.'''
-* Objects are instances of classes and carry out computations in response to messages.
+* '''Objects are instances of classes and carry out computations in response to messages.'''
 * e.g. : A Ticket is a class which has a price and a destination. An instance of a Ticket is an object which is needed to carry out a journey.
 * OO Development implies using classes and objects '''''throughout''''' the construction process - requirements analysis, design, coding and testing.

← Older revision		Revision as of 15:08, 3 January 2012
Line 21:		Line 21:

	* Quite simply, the use of classes and objects in developing software and systems.		* Quite simply, the use of classes and objects in developing software and systems.
		+	* Classes represent recurring, reusable, extensible concepts that provide services. A class is an informational abstraction, representing a concept, some information, a facility as a type that can be instantiated
		+	* Objects are instances of classes and carry out computations in response to messages.
		+	* e.g. : A Ticket is a class which has a price and a destination. An instance of a Ticket is an object which is needed to carry out a journey.
	* OO Development implies using classes and objects '''''throughout''''' the construction process - requirements analysis, design, coding and testing.		* OO Development implies using classes and objects '''''throughout''''' the construction process - requirements analysis, design, coding and testing.

@@ Line 6: / Line 6: @@
 * OO is particularly useful to build such systems.
 * Remember OO is not always the best approach, but is useful in the ''right'' setting.
 == When to use OO ==

← Older revision		Revision as of 12:34, 30 October 2011
Line 1:		Line 1:
		+	= Introduction =

		+	== Why OO ==
		+
		+	* Modern systems are large and complex - lots of interconnected components, distributed and heterogeneous.
		+	* OO is particularly useful to build such systems.
		+	* Remember OO is not always the best approach, but is useful in the ''right'' setting.
		+
		+	== When to use OO ==
		+
		+	* For the systems where the user is in control e.g. decision support systems, CRM's, enterprise systems. OO makes it easier to model such systems.
		+	* Systems where long term extensibility is important. Again OO's concepts make it easier to incorporate extensibility.
		+
		+	== What is OO Development ==
		+
		+	* Quite simply, the use of classes and objects in developing software and systems.
		+	* OO Development implies using classes and objects '''''throughout''''' the construction process - requirements analysis, design, coding and testing.
		+
		+	== Development Methods ==
		+
		+	* Waterfall - doesnt work for large systems
		+	* Spiral - emphasizes risk and cost
		+	* RUP - Rational Unified Process from IBM Rational. User stories are constructed from which OO designs will be built.
		+	* Use cases are a way to write user stories.
		+	* Model Driven Development
		+	** Aim to build software using abstract models. RUP is a kind of MDD.
		+	** Models are at a higher level abstraction than code.
		+	** UML is a popular modeling language.
		+
		+	== Modeling ==
		+
		+	* Create models at each phase, requirements, design etc.
		+	* Capture the essence of things of interest - not everything.
		+	* Hence models are easier to change - but is difficult to keep the model in sync with the actual system.
		+
		+	== UML ==
		+
		+	* A visual language for describing many aspects of system design and requirements.
		+	* UML is '''''only a language''''' and NOT a method or process. UML is typically used with an agile process, although the process can be used without UML.
		+	* A method = language + process + tools.
		+	* UML consists of two parts:
		+	# The graphical notation used to draw models.
		+	# A metamodel: which specifies the validity of models.
		+	* The graphical notation consists of various diagrams such as class, communication, state charts, use case diagrams etc.
		+
		+	== Software Quality ==
		+	* One of the primary goals of SE is to produce quality software.
		+	* How can quality be measured ?
		+	** Internal characteristics: Maintainability, flexibility, testability etc
		+	** External : Correctness, robustness, reliability, usability etc
		+	* So, again '''why OO''' ? OO is ''one'' technique improve internal construction and design of a system to improve software quality.
		+
		+	=== Quality in OO Systems ===
		+	* High quality OO systems will be non-monolithic - high cohesion, low coupling.
		+	* Heuristics exist to build high quality OO systems:
		+	* Direct Mapping Rule
		+	** The class structure in the system must relate (clear mapping) to the structure in the model.
		+	** But in practice, difficult to describe customer requirements, which tend to be goal/event based using classes/objects.
		+	** So we need modeling things such as use cases and interactions.
		+	** Consequently using an OO ''modeling'' language with an OO ''programming'' language is helpful.
		+	** OO model language with non OO programming language is problematic.
		+	[How will you model systems which are written in non OO languages then ?]
		+	* Coherent Interfaces Rule
		+	** A class and its interfaces should represent a coherent view of some concept in the problem or solution domain. e.g. Bank Account, Flight Plan, Player. This relates to high cohesion.
		+	* Small Interfaces Rule
		+	** When two objects communicate, they should exchange as little information as possible. This relates to weak or low coupling.
		+	* Explicit Interfaces Rule
		+	** When two objects are communicating, this must be obvious from their class definitions. The conversations need to be clearly visible - to facilitate understanding.
		+	* Information Hiding Rule
		+	** AKA Encapsulation. Data must be hidden, kept private so that client objects are kept independent of implementation.
		+	* Open-Closed principle
		+	** Class should be open i.e. easily extensible and it should be closed to allow usage (well-encapsulated).

	[[Category:OODE]]		[[Category:OODE]]