CLASS DESIGN THEORY
Object Oriented Approach
Object orientation is a set of design principles based on the conceptually autonomous
computer structures known as objects.
An object represents a real world entity with the ability to interact with itself and other
objects.
Objects have attributes, identity and behaviour
Objects are instances of a class.
o An object-oriented program consists of sets of computing objects.
o Each object has data and program logic encapsulated within itself. Analysts define the
structure of the program logic and data fields by defining a class.
o The class definition describes the structure or a template of what an executing object looks
like.
o The object itself doesn’t come into existence until the program begins to execute.
,ANALYSIS DESIGN
2 types of information requirements:
1. Information about things
- Domain model class diagram
2. Information about the business processes
- Use case descriptions
- Activity diagram
- System sequence diagrams
Classes:
Class: Category or classification used to describe a collection of objects
Domain class model: Describes objects in the systems domain
Design class: Refinement of domain classes for programmers to implement
Domain Class Models:
Shows things in the users domain
- Lines represent association between classes
- Association is indicated by 0, 1 or many (*)
- Association can be included for clarity
,Relationships amongst classes
- Association indicated by 0, 1 or
Association Relationship many
- Solid or dashed association
- One class is a component or part of
another class
- Aggregation: the whole can exist
Whole/Part (aggregation and composition)
without its parts
- Composition: sub parts cannot exist
independently
- Ranking from more general to
specific e.g. motor vehicles vs.
types of cars.
- Inheritance allows subclasses to
Generalization / Specialization
share the attributes of superclass
- Abstract classes (italics) are types of
objects and concrete classes has
actual objects
Notation:
DESIGN
CLASS DIAGRAMS
Stereotype: way of categorizing a model element as a certain type
Persistent class: class whose objects exist after a system is shut down ( data remembered )
Entity class: design identifier for a problem domain class
Boundary class or view class: Class that exists on a systems automation boundary, such as an input
window form or Web page and all the other classes associated with the user interface
Controller class: class that mediates between boundary classes and entity classes, acting as a
switchboard between the view layer and domain layer
Data access class: class that is used to retrieve data from and send data to a database
Concrete class: Class that can be instantiated
Abstract class: Class that cant be instantiated
, NOTATION
Attributes:
- Visibility ( private (-) , public (+) )
- Attribute name (Lower case camelback notation)
- Type expression (class, string, integer, double, date
- Initial value (if applicable default value)
- Property ( if applicable, such as key)
- Example: accountNo: String {key}
Object Oriented Approach
Object orientation is a set of design principles based on the conceptually autonomous
computer structures known as objects.
An object represents a real world entity with the ability to interact with itself and other
objects.
Objects have attributes, identity and behaviour
Objects are instances of a class.
o An object-oriented program consists of sets of computing objects.
o Each object has data and program logic encapsulated within itself. Analysts define the
structure of the program logic and data fields by defining a class.
o The class definition describes the structure or a template of what an executing object looks
like.
o The object itself doesn’t come into existence until the program begins to execute.
,ANALYSIS DESIGN
2 types of information requirements:
1. Information about things
- Domain model class diagram
2. Information about the business processes
- Use case descriptions
- Activity diagram
- System sequence diagrams
Classes:
Class: Category or classification used to describe a collection of objects
Domain class model: Describes objects in the systems domain
Design class: Refinement of domain classes for programmers to implement
Domain Class Models:
Shows things in the users domain
- Lines represent association between classes
- Association is indicated by 0, 1 or many (*)
- Association can be included for clarity
,Relationships amongst classes
- Association indicated by 0, 1 or
Association Relationship many
- Solid or dashed association
- One class is a component or part of
another class
- Aggregation: the whole can exist
Whole/Part (aggregation and composition)
without its parts
- Composition: sub parts cannot exist
independently
- Ranking from more general to
specific e.g. motor vehicles vs.
types of cars.
- Inheritance allows subclasses to
Generalization / Specialization
share the attributes of superclass
- Abstract classes (italics) are types of
objects and concrete classes has
actual objects
Notation:
DESIGN
CLASS DIAGRAMS
Stereotype: way of categorizing a model element as a certain type
Persistent class: class whose objects exist after a system is shut down ( data remembered )
Entity class: design identifier for a problem domain class
Boundary class or view class: Class that exists on a systems automation boundary, such as an input
window form or Web page and all the other classes associated with the user interface
Controller class: class that mediates between boundary classes and entity classes, acting as a
switchboard between the view layer and domain layer
Data access class: class that is used to retrieve data from and send data to a database
Concrete class: Class that can be instantiated
Abstract class: Class that cant be instantiated
, NOTATION
Attributes:
- Visibility ( private (-) , public (+) )
- Attribute name (Lower case camelback notation)
- Type expression (class, string, integer, double, date
- Initial value (if applicable default value)
- Property ( if applicable, such as key)
- Example: accountNo: String {key}
