Designing Classes

1
Designing Classes

• UML Class Diagrams

2
The Implementation and Interface of a Component
(1)

• Interface (Public/Exposed part)
• Data and processes that act on data
• The interface is the public part
• The part of the black box seen by the developer
• These are the exposed fields, properties,
  methods, and events exposed to the developer
• Implementation (Private/Hidden part)
• That part of the component hidden from the
  developer

3
The Implementation and Interface of a Component
(2)

• Encapsulation
• The coupling of data and processes
• Only a process (method) should be able to modify
  data
• Developers should never be able to modify data
  directly
• Only processes may change an objects state
• I should only be able to decrease my bank balance
  by making a withdrawal
• Properties and methods are encapsulated to form a
  component
• Components are reusable by many developers

4
Components (Examples)

• The StreamReader is a component with exposed
  methods and a hidden implementation
• The TextBox is a component

5
The Role of Author and Developer

• I formalize the role of two entities
• Authors model, design, and create components
• This includes both the interface and the
  implementation
• Developers use the components created by authors
• Developers can only see the exposed part of the
  component (the interface)
• You will act in both roles as you develop and
  test classes

6
Benefits of Component-Based Programming

• Improves programmer productivity
• Components can be shared by multiple applications
• Reduces software development costs
• A components implementation can be changed so
  long as the interface does not change
• Improves reusability and reduces software
  maintenance costs
• Components help enforce standardization across
  organizational entities

7
Introduction to Modeling Components with the UML

• UML Class diagrams model system components
  (classes) and their relationships with each other
• Attributes model data stored in a class
• Attributes are "roughly" equivalent to .NET
  properties
• Operations represent the actions that a class can
  carry out
• Operations are implemented as methods (Function
  procedures and Sub procedures)
• Attributes and operations may be exposed or hidden

8
Introduction to UML Class Diagrams

• Visually, a class is enclosed in a rectangle
• The rectangle has three regions
• The top region contains the class name
• The middle region contains the attributes
• The lower region contains the operations
• There is an optional responsibilities class in a
  fourth section

9
Class Names

• Class names are of two types
• A simple name is just a textual string
• A path name is prefixed by the package in which
  the class lives
• In Java, these are called packages
• In .NET, these are called namespaces

10
Setting Class Names (Visio)
11
Class Name (Illustration)
Class Name
12
Class Attributes

• An attribute is a named property of a class
• A class may have many attributes or none at all
• In a UML class diagram, an attribute has
• A name
• Visibility
• An optional data type
• An optional default value

13
Setting Class Attributes (Visio)
14
Class Attributes (Illustration)
Class Attributes
Visibility (,-)
15
Class Operations

• An operation is something an object can do
• A class may have many operations or none at all
• In a UML class diagram, an operation has
• A name
• An optional signature
• An optional return data type
• Operations and Attributes can be grouped by
  category using stereotypes
• We will not discuss stereotypes here

16
Creating Class Operations (Visio)
17
Class Operations (Illustration)
18
Class Responsibilities

• A responsibility is a contract or obligation of a
  class
• A class should have one or very few
  responsibilities
• A responsibility is short and consists of
  free-from text

19
Class Relationships

• Classes do not exist in a vacuum
• There are "most often" relationships between
  classes
• Relationships can be categorized into three
  types
• Dependencies
• Generalizations
• Associations
• In UML Class diagrams, relationships are depicted
  using lines between classes

20
Class Relationships (Dependencies)

• Dependencies are "using" relationships
• A car depends on an engine
• A change in one thing will affect the other thing
• Dependencies are typically one-way
• Dependencies are depicted as a dashed directed
  line
• The arrow points to the thing being depended on
• The car class would point to the engine class

21
Class Relationships (Dependencies) (Illustration)
22
Class Relationships (Generalizations)

• A relationship between a general thing and a
  specific thing
• Often referred to as an "is-a" relationship
• A student "is-a" person
• An SUV is an automobile
• A circle is a shape
• Generalizations are depicted as a solid directed
  line
• An unfilled arrow points from the specific class
  to the general class
• More later when we talk about inheritance

23
Class Relationships (Associations)

• An association is a relationship between two
  classes
• Associations that connect exactly two classes are
  called binary associations
• Associations can have names
• There are specialized forms of associations
• Aggregation
• Compositions

24
Class Relationships (Aggregation)

• Associations in which an object is part of a
  whole is an aggregation
• The part class may be a part of another whole
• Aggregation relationships are depicted with an
  unfilled diamond pointing from the part to the
  whole

25
Class Relationships(Aggregation Illustration)
26
Class Relationships(Composition)

• Composition is a stronger form of aggregation
• A composition relationship exists when the part
  can ONLY belong to one whole

27
Class Relationships (Composition Illustration)
28
Associations (Multiplicity)

• Multiplicity specifies how many objects can exist
• 1 (One instance must exist)
• 0..1 (Zero or 1 instance can exist)
• (Zero, 1, or many instances can exist)