Software Design Basics

Object Oriented Programming

In class-based OOP languages, any object must be an instance of a class (an abstraction or model). An object has:

• state (its properties or attributes, which are declared through data fields)
• behavior (its set of operations, or responsibilities which are defined by the instance methods that implements that behavior.)

There is also functional programming and prototype-based OOP languages like JavaScript.

Encapsulation

Objects encapsulate their state and behavior in a unit with an interface that allows access for the user.

• A class is a unit of encapsulation.

The state is typically private to the object and not visible to its clients. The concept of denying direct access is called information hiding.

The set of visible behavior of an object forms its interface and defines how it collaborates (acts and reacts) with other objects.

Inheritance and Polymorphism

A superclass/subclass relationship may exist between two classes when one class "is a kind of" the other class. Subclasses inherit the structure and behavior of their superclass.

Polymorphism is the ability of an entity of an OO model to refer to obejcts of different classes at different times.

Unified Modeling Language

UML is the standard notation for OOAD. UMLs define the structure or behavior of the software system. The class diagram illustrates th enecessary classes and their relationships.

A class is represented by a box. and it can include attributes (data fields) and operations (methods)

• name: type
• + means public, - means private, # means protected, and / means derived.
• Operations appear as method(type): return_type.
• Static methods/fields are indicated by underlining
• Constant fileds are in all caps
• Abstract methods are in italics.

Relationships include

Dependencies: when a class uses the other one. It can also indicate a semantic relationship between two classes.

• Use a dotted line with an arrow
• Schedule will have a dependency on Course is used in the add operation of Schedule

Association Relationships model objects that contain other objects. It represents a has-a relationship. A class can hold a data field reference to another class.

• Course has a (field of type) Instructor
• Represented by a solid line between two classes.

Multiplicity of an association is done by adding multiplicity adornments to the line denoting the association

• A course has one Instructor
• 1..* would mean that an Instructor is associated with (teaches) one or more course

The role of an object in an association can be indicated using Role names.

• Text at the edge of the line

Name the associatiion

• by naming the line itself

You can specify more than one association on a pair of classes.

Constrain the association relationship by defining the navigability of the association. - A Router requests services from DMS so it points to it. DMS has no knowledge of Router.

A self association is done by looping onto itself.

Aggregation specifies a whole-part relationship between an aggregate (a whole) and a constituent part (can exist independently from aggrgate).

• Denoted by a hollow-diamond adornmen ton the association
• Car has a Transmission and Engine

Composition indicates a strong ownership and coincident lifetime of parts by teh whole.

• Demoted by a filled-diamond adornment on the association.
• A Window has a Scrollbar, Titlebar, and Menu

Generalization Relationship specifies "is a kind of" (simply is-a) relationship. Used to depict inheritance hierarchy. - UndergradStudent and GraduateStudnet are each derived from the class Student. - represented by an arrow with a hollow head pointing to the superclass

If a class implements an interface, draw the arrow having a dotted shaft.