CMPT 370: Information Systems Design

1
CMPT 370 Information Systems Design
Lecture Topic Concepts to Classes Class
Exercise Class Diagrams

• Instructor Curtis Cartmill, Simon Fraser
  University Summer 2003

2
Objectives

• This lecture looks at moving from analysis to
  design. This is the first of several lectures
  where we focus on techniques (diagramming) to add
  to our skills in modeling
• Class diagram vocabulary back to Chapter 2
• Class design choices drawing class diagrams is
  a reflection of making decisions about design
• Leveraging domain model concepts

3
From Analysis to Design

• The line between What is Analysis? and What is
  Design? is very fuzzy
• We will move between the two as we both try to
  understand the problem as well as create the
  solution

4
Design

• Design encompasses two major issues
• Detailed Design
• Realization of system functionality as captured
  in use cases
• Elaboration of the analysis with considerations
  for implementation
• Architectural design
• Layering and organization of classes and packages
• Assignment of processes to computing facilities
• Re-use and component management

5
Concepts to Classes

• Our work around CRC leads us naturally to
  thinking about class design
• Concepts -gt Classes
• Responsibilities
• What does the class know -gt attributes
• What does the class know how to do -gt operations

6
Class

• A class is a descriptor of a set of objects with
  the same attributes and operations.
• Classes serve as templates for objects (instance)
• Each object created from the template (the
  instantiation process) contains the attribute
  values that conform to the attribute types
  defined in the class.
• Each object can invoke operations defined in the
  class

7
Attributes

• An attribute is a type value pair
• classes define the attribute type
• objects define the attribute value
• An attribute type can be a built-in primitive
  (primitive data type) or it can be another class
• a primitive is a class that is understood and
  supported by the underlying object-oriented
  software environment
• integer, string etc.
• what is considered a primitive then is dependent
  on the language of implementation

8
Operations

• An operation is a behaviour exhibited by all
  objects of a class
• Operations are implemented as Methods
• The three terms, operation, behaviour and method
  are used interchangeably.
• The operation can contain a list of parameters
  that can be set to specific values when the
  operation is invoked
• The operation can return a value to the calling
  object
• Method Signature is referred to as the
  combination of the operation name together with a
  list of formal argument types, and return type

9
Class Responsibilities

• Knowing responsibilities include
• Data, related objects, things that it can derive
  or calculate
• Doing responsibilities include
• Doing something by itself, initiating
  responsibilities in other classes/objects,
  controlling or coordinating activities in other
  classes/objects
• Which class is responsible for knowing/doing .?
• That (class) which knows (data) does
  (operations).
• The translation of responsibilities into
  methods/operations is influenced by the
  granularity of the responsibility.
• Methods are implemented to fulfill
  responsibilities

10
Class example

• Attribute names and method names are descriptive
• Attributes are private, methods are either public
  or private
• Upper case and lower case are indicative of Class
  and Object,
• upper case -gtClass,
• lower case -gt Object

11
Encapsulation

• Attributes are private to enforce encapsulation
• The only way values within an object can be
  changed are through an objects operations.
• Also called information hiding

12
Generalization

• Generalization is a kind of relationship
  between a generic class and a more specialized
  kind of that same class.
• This is a superclass subclass relationship
• Makes it unnecessary to restate already defined
  properties

13
Polymorphism
Polymorphism allows a method signature to be
identical across various classes yet have the
method perform different behaviour Polymorphism
is used in overriding attributes and operations
in a generalization relationship, but can also be
used in other cases
14
Inheritance

• Permits the incremental description of a subclass
  by reusing and then extending superclass
  descriptions
• i.e. If GraduateCourse.register() did some work,
  and in it called its parent Course.register() to
  do some delegation of work
• Polymorphism relies on Inheritance
• Multiple Inheritance is when a subclass can
  inherit from more than one superclass
• Can lead to conflicts in inherited attributes or
  methods from multiple parents
• Some languages use Single Inheritance coupled
  with Interfaces to simulate Multiple Inheritance

15
Abstract classes
Abstract class is a class that does not have any
object instances. At least one of the abstract
class operations are abstract (signature is
defined, but method implemented in the subclass)
A class can be abstract only if all of the
subclasses constitute the entire set of objects
that can be instantiated
16
Class Association

• In Concept Diagrams, classes are associated
  through association relationships which are
  binary
• A university offers courses
• A course is offered by a university

17
Class Association

• In Class Diagrams, classes are associated
  through link attributes
• All associations are has
• All associations are one way
• Hollow diamond indicates aggregation
• Filled diamond indicates composition

18
Aggregation and Composition

• Aggregation is a whole-part relationship between
  a class representing an assembly of components
  and the classes representing the components.
• Aggregation aggregation by reference (weak)
• Composition aggregation by value (strong)
• The life/existence of the object is dependent on
  the life/ existence of the relationship

19
Aggregation and Composition

• Aggregation aggregation by reference (weak)
• Textbook Example Crate contains Beer Bottles
• Composition aggregation by value (strong)
• Textbook Example Book has Chapters, and a
  Chapter has Sections (Chapters and Sections
  couldnt exist without Book)

20
Notes on Class Diagrams

• Usually Aim to show the following information
• Classes, Associations and Attributes
• Interfaces with Operations and Constants
• Methods
• Navigability (Attribute Visibility of Classes)
• Dependencies
• Getters and setters are implied and are not
  necessarily modeled
• UML has a ltltcreategtgt method implied for classes
• Aggregations are modeled as Collection type
  relationships
• Redundant to put in attributes with the
  relationship. Implied that the relationship (and
  thus attribute) is named by the Class name. May
  not always be the case

21
Class Diagram Syntax Semantics (1)
22
Class Diagram Syntax Semantics (2)
23
Class Diagram Examples
24
Class Diagram Examples
25
Advanced Topics for Classes

• Classifiers Interface, Datatype, Signal,
  Component, Node, Use Case, Subsystem
• Visibility public, private, protected
• Scope Instance (object) or Class (static)
• Elements Abstract, Root, Leaf, and Polymophism
• Multiplicity (if applicable, top-right corner)
• Attributes (visibility, type, properties
  frozen)
• Operations (direction in/out, guarded,
  concurrent, etc.)
• Template Classes (Specify Template Parameters)

26
Class Exercise

• Simple Class Diagram
• Class Diagram with Domain Model Information as
  set of first-iteration classes
• Complex Class Diagram Scenario
• Strategies for using a variety of Artifacts to
  generating Class Diagrams