Difference between revisions of "OODE"

From Suhrid.net Wiki
Jump to navigationJump to search
 
(46 intermediate revisions by the same user not shown)
Line 16: Line 16:
 
* 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.
 
* 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.
 +
 +
== 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).
 +
 +
= UML =
 +
 +
* A family of visual languages to describe systems (not necessarily but usually software systems).
 +
* UML is not a research project - it is a collection of practices gained through industry usage.
 +
* A system can be viewed through different perspectives. E.g. a house can be viewed differently by the landlord, tenant, plumber, architect, tax officials view.
 +
* In UML, different kind of diagrams allow us to have views about the system in different ways.
 +
** e.g. use case diagram represent system functions from the user perspective, sequence diagram is representation of objects and their temporal interactions etc.
 +
 +
== Classes ==
 +
 +
* A class is an intentional description ( a blueprint) of set of objects.
 +
* A description can be thought of as : 1) a specification and 2) a realization. In UML practice, these are usually combined.
 +
* Class diagrams represent a set of classes, interfaces, collaborations and their relationships.
 +
* They offer a static conceptual view of the system.
 +
 +
=== Relations between classes ===
 +
 +
 +
* '''Association :''' Represents a connection between '''instances''' of the classes. (''not between the classes themselves''). By default an association is bidirectional.
 +
* As in a representation of the references to other instances that an instance has.
 +
* A role is attached to the end of an association. The role also has a multiplicity. '''''Make sure both of these are represented.'''''
 +
* For e.g. a Manager and an Employee's association role can be "manager" with multiplicity of 1 on the Manager end (each Employee has 1 manager) can and 1..* (each manager has 1 or more employees) on the Employee end.
 +
* Navigability: A direction can be imposed on an association. This means that the destination object will have a direct reference from the source object, but not the other way around.
 +
* for e.g. a User object can have references to Password objects, but not the other way around, since it will be a security risk.
 +
 +
 +
* '''Aggregation :''' Represents '''asymmetric bidirectional''' semantic connections.
 +
* Represents '''a stronger coupling''' between classes. for e.g. a company is made up of a number of departments.
 +
* Generally for relations as whole and part, master and slave, composed and composing.
 +
* Notation : a white diamond at the aggregation point. for e.g the white diamond will be at the end of the company.
 +
 +
 +
* '''Composition :''' Represents a '''stronger''' form of aggregation.
 +
* Maximum multiplicity of 1 on the aggregate side : An object may be part of only 1 composite at a time, whereas it can be part of more than 1 aggregate.
 +
* Automatic propagation of destruction. If a composite is destroyed, so will be its parts.
 +
* For e.g. a relation between a Engine and Pistons. If the engine is destroyed, so are the pistons.
 +
* Represented by a filled in diamond at the end of the aggregation.
 +
 +
 +
* '''Generalisation :''' Represents an IS-A relationship.
 +
 +
 +
 +
* '''Dependency :'''  A weaker relationship than association.
 +
* TODO : Look this up for more information.
 +
 +
== Packages ==
 +
 +
* Used for model structuring - way to group classes.
 +
* Corresponds to a Java Package.
 +
 +
== Stereotypes ==
 +
 +
* A stereotype extends the UML Vocabulary.
 +
* Enables us to create new kinds of basic elements deriving from existing elements in the UML Metamodel.
 +
* e.g. modeling Java Exceptions can be turned into basic elements in the model.
 +
* TODO: come up with a good example.
 +
 +
 +
== Notes ==
 +
 +
* Useful for comments. Belongs to the '''view''', '''not''' the model.
 +
* Since a note doesnt belong to the model, it can be stereotyped as a constraint.
 +
 +
== Constraints ==
 +
 +
* A conditional relationship between model elements.
 +
* Expressed in OCL or in natural language.
 +
* TODO: Add a meaningful example.
 +
 +
== Objects ==
 +
 +
* Represent run-time system behaviour.
 +
* Use object diagrams.
 +
* An object diagram is like a class diagram, except it is named differently. e.g. <u>ObjName:Class</u>
 +
 +
* Three diagram types of object:
 +
 +
=== Object Diagram ===
 +
 +
* Represents the structure of objects at run time, since object behaviour is dynamic, this is effectively a snapshot.
 +
* Also represent the links between the objects.
 +
* The links are '''instances of the class associations.'''
 +
* An object diagram '''is an instance''' of a class diagram.
 +
 +
=== Communication Diagrams ===
 +
 +
* Sequence and Collaboration diagrams are interchangeable - they can be transformed into one another.
 +
 +
==== Sequence Diagram ====
 +
 +
* focus on the chronological ordering of messages.
 +
 +
* It is a temporal vision of an interaction : It is for a '''''particular''''' interaction or a scenario.
 +
* Often used to represent a use case scenario.
 +
* A filled in arrow represents a synchronous call.
 +
* A blank arrow represents a asynchronous call.
 +
 +
==== Collaboration Diagram ====
 +
 +
* Focus on the structural organization of the elements sending the messages.
 +
* Represents a collaboration between roles. Focuses on the structure, not that much on the time.
 +
* Time ordering can be shown by numbering notations.
 +
 +
==== Statechart: Represent state automata ====
 +
 +
* Activity Diagram: Special kind of statechart - describing series of activities within systems.
 +
* '''Important in system function modeling''' - focusing on control flow in objects.
 +
* The fork - join concept is important. Fork can be used to represent concurrent activities.
 +
 +
=== Component and Deployment Diagrams ===
 +
 +
* Component Diagram:
 +
* A component is a set of classes, interfaces or collaborations
 +
* A component diagram represents the organization and dependencies between the components.
 +
* [TODO] Give a good example.
 +
 +
* Deployment Diagram:
 +
* Deployment diagrams show the static deployment view of an architecture. They are linked to component diagrams.
 +
* [TODO] Give a good example.
 +
 +
 +
=== Use Case Models ===
 +
 +
* See REQE's Use Case Models Page.

Latest revision as of 05:00, 30 October 2011

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:
  1. The graphical notation used to draw models.
  2. 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).

UML

  • A family of visual languages to describe systems (not necessarily but usually software systems).
  • UML is not a research project - it is a collection of practices gained through industry usage.
  • A system can be viewed through different perspectives. E.g. a house can be viewed differently by the landlord, tenant, plumber, architect, tax officials view.
  • In UML, different kind of diagrams allow us to have views about the system in different ways.
    • e.g. use case diagram represent system functions from the user perspective, sequence diagram is representation of objects and their temporal interactions etc.

Classes

  • A class is an intentional description ( a blueprint) of set of objects.
  • A description can be thought of as : 1) a specification and 2) a realization. In UML practice, these are usually combined.
  • Class diagrams represent a set of classes, interfaces, collaborations and their relationships.
  • They offer a static conceptual view of the system.

Relations between classes

  • Association : Represents a connection between instances of the classes. (not between the classes themselves). By default an association is bidirectional.
  • As in a representation of the references to other instances that an instance has.
  • A role is attached to the end of an association. The role also has a multiplicity. Make sure both of these are represented.
  • For e.g. a Manager and an Employee's association role can be "manager" with multiplicity of 1 on the Manager end (each Employee has 1 manager) can and 1..* (each manager has 1 or more employees) on the Employee end.
  • Navigability: A direction can be imposed on an association. This means that the destination object will have a direct reference from the source object, but not the other way around.
  • for e.g. a User object can have references to Password objects, but not the other way around, since it will be a security risk.


  • Aggregation : Represents asymmetric bidirectional semantic connections.
  • Represents a stronger coupling between classes. for e.g. a company is made up of a number of departments.
  • Generally for relations as whole and part, master and slave, composed and composing.
  • Notation : a white diamond at the aggregation point. for e.g the white diamond will be at the end of the company.


  • Composition : Represents a stronger form of aggregation.
  • Maximum multiplicity of 1 on the aggregate side : An object may be part of only 1 composite at a time, whereas it can be part of more than 1 aggregate.
  • Automatic propagation of destruction. If a composite is destroyed, so will be its parts.
  • For e.g. a relation between a Engine and Pistons. If the engine is destroyed, so are the pistons.
  • Represented by a filled in diamond at the end of the aggregation.


  • Generalisation : Represents an IS-A relationship.


  • Dependency : A weaker relationship than association.
  • TODO : Look this up for more information.

Packages

  • Used for model structuring - way to group classes.
  • Corresponds to a Java Package.

Stereotypes

  • A stereotype extends the UML Vocabulary.
  • Enables us to create new kinds of basic elements deriving from existing elements in the UML Metamodel.
  • e.g. modeling Java Exceptions can be turned into basic elements in the model.
  • TODO: come up with a good example.


Notes

  • Useful for comments. Belongs to the view, not the model.
  • Since a note doesnt belong to the model, it can be stereotyped as a constraint.

Constraints

  • A conditional relationship between model elements.
  • Expressed in OCL or in natural language.
  • TODO: Add a meaningful example.

Objects

  • Represent run-time system behaviour.
  • Use object diagrams.
  • An object diagram is like a class diagram, except it is named differently. e.g. ObjName:Class
  • Three diagram types of object:

Object Diagram

  • Represents the structure of objects at run time, since object behaviour is dynamic, this is effectively a snapshot.
  • Also represent the links between the objects.
  • The links are instances of the class associations.
  • An object diagram is an instance of a class diagram.

Communication Diagrams

  • Sequence and Collaboration diagrams are interchangeable - they can be transformed into one another.

Sequence Diagram

  • focus on the chronological ordering of messages.
  • It is a temporal vision of an interaction : It is for a particular interaction or a scenario.
  • Often used to represent a use case scenario.
  • A filled in arrow represents a synchronous call.
  • A blank arrow represents a asynchronous call.

Collaboration Diagram

  • Focus on the structural organization of the elements sending the messages.
  • Represents a collaboration between roles. Focuses on the structure, not that much on the time.
  • Time ordering can be shown by numbering notations.

Statechart: Represent state automata

  • Activity Diagram: Special kind of statechart - describing series of activities within systems.
  • Important in system function modeling - focusing on control flow in objects.
  • The fork - join concept is important. Fork can be used to represent concurrent activities.

Component and Deployment Diagrams

  • Component Diagram:
  • A component is a set of classes, interfaces or collaborations
  • A component diagram represents the organization and dependencies between the components.
  • [TODO] Give a good example.
  • Deployment Diagram:
  • Deployment diagrams show the static deployment view of an architecture. They are linked to component diagrams.
  • [TODO] Give a good example.


Use Case Models

  • See REQE's Use Case Models Page.