Goals of Lecture

• Cover Mathiassen’s method for component

Lecture 26: OO Design Methods: design (e.g. low-level design)
Mathiassen, Part 6 • Activities
– Model Component
Kenneth M. Anderson
– Function Component
Object-Oriented Analysis and Design
– Connecting Components
CSCI 6448 - Spring Semester, 2001

April 19, 2001 © Kenneth M. Anderson, 2001 2

Component Design Component Design

• Purpose • Last step before implementation
– To determine an implementation of requirements within an
architectural framework • Previous Steps
• Definitions – Problem Domain Analysis
– Component: A collection of program parts that constitutes a whole
and has well-defined responsibilities – Application Domain Analysis
– Connection: The implementation of a dependency relation – Architectural Design
• Principles
– Respect the component architecture
• Meaning of First Principle
– Adapt component designs to the technical possibilities – Do not change the architectural design for short
• Results term advantage
– A description of the system’s components
April 19, 2001 © Kenneth M. Anderson, 2001 3 April 19, 2001 © Kenneth M. Anderson, 2001 4
 Component Design Model Component Design
• Input • Purpose
– To represent a model of a problem domain
– Architectural Specifications • Definitions
• Steps (Page 232) – Model Component: A part of the system that implements the
problem domain model
– Design Components – Attribute: A descriptive property of a class or an event
• Both Model and Function • Principles
– Design Component Connections – Represent Events as classes, structures, and attributes
– Choose the simplest representation of events
• Output • Results
– Component Specifications – A class diagram of the model component;
note: component ≠ class
April 19, 2001 © Kenneth M. Anderson, 2001 5 April 19, 2001 © Kenneth M. Anderson, 2001 6

Background Designing the Model Component

• Central Concept: Structure • Input
– Model Components should reflect structure of problem – Class Diagram
domain’s relevant conceptual relations – Behavioral Patterns
– Component Specs from Arch. Design
• Foundation • Steps (page 239)
– OO Model of Problem Domain Analysis – Represent Private Events
• Main Task – Represent Common Events
– Represent problem domain events using mechanisms of – Restructure Classes
OO programming languages • Output
– Model Component Specification
• Results
• Example: Figure 12.1, 12.2, 12.4
– Revised problem-domain class diagram
April 19, 2001 © Kenneth M. Anderson, 2001 7 April 19, 2001 © Kenneth M. Anderson, 2001 8
 Background Step 1: Represent Private Events
• Key concept of problem-domain analysis returns • Private Events involve only one problem
– Events! (Event Tables guide process of model component design)
domain object
• Events
– are grounded in problem domain – Use Event Table to identify private events
– have attributes
• Use guidelines of figure 12.5 to modify
– cause model updates when they occur
• Behavioral Patterns
problem-domain class diagram
– Specify legal traces of events – Single events: store attributes in class
• Method: Use behavioral patterns to determine information – Multiple events: create new event class
the model components must capture

April 19, 2001 © Kenneth M. Anderson, 2001 9 April 19, 2001 © Kenneth M. Anderson, 2001 10

Step 2: Represent Common

Example: Customer Class
Events
• Has two private events (Fig. 12.2) • Common Events involve more than one problem-
– Credit Approval domain object
• Attributes: date, name, address
• Guidelines
– Change Address
• Attributes: date, address – Choose one object to represent the event
• Represent Events (Figure 12.6) – All other objects access event info via structural
– Credit Approval occurs once relationships
• Add attributes to customer class • Heuristic
– Change Address can happen more than once – Choose simplest structure
• Create new class; each instance corresponds to one occurrence • Use event table to guide you
of the event
April 19, 2001 © Kenneth M. Anderson, 2001 11 April 19, 2001 © Kenneth M. Anderson, 2001 12
 Example: Customer and Account Step 3: Restructure Classes
• Open Account and Close Account • Simplify Revised Class Diagram
– Occur only once for each account – Generalization (Figure 12.10)
– Occur multiple times for Customer • Multiple classes might be replaced a common
– Simplest Representation superclass
• Attributes on Account Object
– account state, opendate, closedate
– Association (Figure 12.11)
• Some associations may be obsolete
• Deposit and Withdraw
– Occur multiple times for both customer and account – Embedded Iterations (Figure 12.12 and 12.13)
– Need to evaluate multiple options and choose simplest • Simple analysis models may not specify enough
structure; see Figure 12.9 information to produce correct designs

April 19, 2001 © Kenneth M. Anderson, 2001 13 April 19, 2001 © Kenneth M. Anderson, 2001 14

Function Component Design Background

• Purpose
– To determine the implementation of functions
• Behavior in OO systems is described as
• Definitions operations on a system’s classes
– Function Component: A part of a system that implements functional
requirements
– Behavior is activated by invoking these
– Operation: A process property specified in a class and activated through operations that reside within objects
class objects
• Principles • Since an OO system’s interactions
– Base the design on function types constitute its behavior, and functions are
– Specify Complex Operations
• Results
used to enable interactions, functions must
– A class diagram with operations and specifications of complex operations be implemented by operations
April 19, 2001 © Kenneth M. Anderson, 2001 15 April 19, 2001 © Kenneth M. Anderson, 2001 16
 Step 1: Design Functions as
Model Component Design
Operations
• Inputs • Design functions based on type
– Function List, Class Diagram, Component Specs – Update, Read, Compute, and Signal
– Model Component Specs
• Steps (page 252)
• Figure 13.3 provides guidelines for each type
– Design functions as operations • In general, sequence diagrams can be used to
• Design not implement! Simple operations first! specify operations
– Explore patterns
– Note: I don’t like the diagrams (Figures 13.4-13.7)
– Specify Complex Operations
presented by Mathiassen in this section because they do
• Results not show legal UML
– Modified Model Components, Function Component Specs

April 19, 2001 © Kenneth M. Anderson, 2001 17 April 19, 2001 © Kenneth M. Anderson, 2001 18

Step 3: Specify Complex

Step 2: Explore Patterns
Operations
• Model-Class Placement (Figure 13.8) • Operations can be specified in a number of
– Operations are best placed in a model-component class with
compatible attributes and operations ways
• Function-Class Placement (Figure 13.9) – Textually (Figure 13.12)
– If an operation involves objects from different model components,
then it must be placed in a function component – Graphically
• Strategy (Figure 13.10) • Sequence Diagrams
– Useful in designing an operation that might be implemented in
multiple ways; allows dynamic change of the operation at run-time • State Chart Diagrams
• Active Function (Figure 13.11) • A system’s total behavior can be
– Active functions reside in Active Objects
represented using state charts
April 19, 2001 © Kenneth M. Anderson, 2001 19 April 19, 2001 © Kenneth M. Anderson, 2001 20
Connecting Components Activity Coupling
• Purpose • A negative measure, we wish to minimize it
– To connect system components • Four types
• Definitions – Outside coupling: Class A makes use of the public aspects of Class
– Coupling: A measure of how closely two classes or components B
are connected – Inside Coupling: Operation A refers directly to private properties
– Cohesion: A measure of how well a class or component is tied of its host class
together – Coupling from below: A subclass refers to private properties of its
• Principle superclass
– Sideways Coupling: A class refers directly to private properties in
– Highly cohesive classes and loosely coupled components
some other class
• Results • Low coupling can be achieved by using outside coupling
– Class Diagram and avoiding sideways coupling

April 19, 2001 © Kenneth M. Anderson, 2001 21 April 19, 2001 © Kenneth M. Anderson, 2001 22

Cohesion Connecting Components

• A positive measure, we try to maximize it • Input
• Properties of Class Cohesion
– Class diagram and Component Specs
– Operations constitute a functional whole
– Attributes and object structures describe objects with well-defined • Steps (page 274)
states
– Operations use each other – Connect Classes
• Properties of Component Cohesion – Explore Patterns
– Component classes are conceptually related – Evaluate Connections
– Structural relations among classes are primarily generalizations
and aggregations • Output
– Key operations can be carried out within component
– Class diagrams and component specs
April 19, 2001 © Kenneth M. Anderson, 2001 23 April 19, 2001 © Kenneth M. Anderson, 2001 24
 Step 1: Connect Classes Step 2: Explore Patterns
• Three types of component connections • Observer
– Aggregating another component’s classes – Basic Structure (Figure 14.5)
(Figure 14.2) • Abstract subject and observer
– Specializing another component’s public class • Concrete subject and observers
(Figure 14.3) – Basic Pattern of Use (Figure 14.6)
– Calling public operations in another – Example of Use (Figure 14.7)
component’s objects (Figure 14.4)
• The call connection is preferred
April 19, 2001 © Kenneth M. Anderson, 2001 25 April 19, 2001 © Kenneth M. Anderson, 2001 26

Step 3: Evaluate Connections

• Evaluate Connections to ensure low
coupling is being achieved
• Figure 14.8 presents a checklist of concerns
for each type of coupling

April 19, 2001 © Kenneth M. Anderson, 2001 27