Knowt
Note
Studied by 7 peopleNoteStudied by 13 peopleNoteStudied by 14 peopleNoteStudied by 3 peopleNoteStudied by 7 peopleNoteStudied by 8 people
Chapter_9-11
Page 1
Title
Object-Oriented Software Engineering: An Agile Unified Methodology by David Kung
Page 2
Key Takeaway Points
A design class diagram (DCD) is a UML class diagram derived from behavioral models and the domain model.
It serves as a blueprint for test-driven development, integration testing, and maintenance.
Package diagrams help organize and manage classes in large DCDs.
Page 3
Acquiring Requirements and Deriving DCD
Requirements Acquisition
Business goals and needs.
Current situation and preliminary requirements.
Iterative Phase Activities
Actor-System Interaction Modeling.
Domain Modeling.
Outputs
Expanded use cases, UI design.
Behavior models and design class diagrams.
Page 4
Design Class Diagram (DCD)
DCD is a structural diagram showing classes, attributes, operations, and their relationships.
May include design patterns.
Basis for implementation and testing; derived from domain model and sequence diagrams.
Page 5
Derivation of DCD
DCD is derived from:
Domain Model (DM): Provides classes, attributes, and relationships.
Sequence Diagrams: Determines classes, methods, and relationships.
Includes design classes (controller, command, GUI) and application classes.
Page 6
Steps for Deriving DCD
Identify all classes from sequence diagrams:
Classes sending or receiving messages.
Classes passed as parameters or return types.
Page 7
Identify Classes from Sequence Diagrams
Example Classes:
Checkout GUI,DBMgr,User,Document,Loan,CheckoutControllerFocus on how objects interact with messages.
Page 8
Identified Classes
List of Classes:
User
Document
Loan
CheckoutGUI
DBMgr
CheckoutController
Page 9
Steps for Deriving DCD (Continued)
Identify methods for each class from sequence diagrams:
Methods indicated by messages on incoming edges of objects.
Details about parameters and return types obtained from the sequence diagram.
Page 10
Identify Methods
Example Methods to Identify:
Checkout GUIandDBMgrexample calls.
Page 11
Fill In Identified Methods
Methods example:
getUser(uid)getDocument(callNo)saveLoan(loan)checkout(uid, cnList)
Page 12
Steps for Deriving DCD (Continued)
Identify and fill in attributes:
Attributes have scalar types, used to get objects.
Found in
getX()andsetX(...)methods or domain model.
Page 13
Identify Attributes from Sequence Diagrams
Example Attributes for
User,Document, etc.
Page 14
Fill In Attributes
Example Attributes Specification:
uid: StringcallNum: StringisAvailable: boolean
Page 15
Steps for Deriving DCD (Continued)
Identify relationships:
An arrow indicates a call and a dependence relationship.
Parameters or return types indicate association or uses relationship.
Page 16
Identify Relationships
Example relationships obtained from sequence diagrams.
Page 17
Fill In Relationships
Indicate relationships with classes in DCD, including dependencies.
Page 18
From Sequence Diagram to Implementation
Example of a
Checkout GUIimplementation derived from sequence diagrams.
Page 19
Applying Agile Principles
Value working software over comprehensive documentation.
Good enough is enough.
Page 20
Transition to Chapter 10
Title change to: Applying Responsibility Assignment Patterns.
Page 21
Key Takeaway Points from Chapter 10
Design patterns are proven solutions to design problems.
Patterns like controller, expert, and creator are widely applicable.
Page 22
Deriving Design Class Diagram in Chapter 10 Context
Emphasizing methodologies and requirements acquisition.
Page 23
What Are Design Patterns?
Improve communication and empower less experienced developers.
Improve maintenance of software systems.
Page 24
Example: The Singleton Pattern
Design Problem: Ensuring a single globally accessible instance.
Page 25
Implementing Singleton Pattern
Example Code:
public class Catalog { ... }
Page 26
Singleton Pattern Representation
UML representation of the Singleton Pattern in design.
Page 27
Describing Patterns
Specify benefits, liabilities, and trade-offs of a pattern.
Page 28
More About Design Patterns
Focus on improving software maintainability and efficiency.
Page 29
Commonly Used Design Patterns
GRASP and Gang of Four Patterns.
Page 30
GRASP Patterns
List: Expert, Creator, Controller, etc.
Page 31
Gang of Four Patterns Overview
Types: Creational, Structural, and Behavioral Patterns.
Page 32
The GoF Patterns Examples
Creational, Structural, and Behavioral patterns annotated.
Page 33
Applying GRASP through Case Study
Evaluate designs and apply GRASP patterns to improve design.
Page 34
Example: Checkout Sequence Diagram
Importance of managing object responsibilities.
Page 35
Problems in Design
Tight coupling and unclear responsibility assignments.
Page 36
A Better Solution
Recommendations for reducing coupling and improving designs.
Page 37
Assigning Actor Requests
Importance of assigning responsibilities to controller classes.
Page 38
The Controller Pattern
Defines actor interactions in the business object layer.
Page 39
Types of Controllers
Use Case, Role, and Facade Controllers defined.
Page 40
Applying the Controller Pattern
Guidelines for choosing controller implementations based on context.
Page 41
Using Use Case Controllers
Each use case having a dedicated controller for clarity.
Page 42
Benefits of The Controller Pattern
Separation of concerns, high cohesion, and reduced coupling.
Page 43
Liabilities of The Controller Pattern
Challenges related to bloated controllers and design complexities.
Page 44
Bloated Controller Issues
Symptoms and impacts of poorly designed controllers.
Page 45
Remedies for Bloated Controllers
Strategies for rectifying bloated controller designs.
Page 46
Class Exercise
Complete the sequence diagram for the "Checkout Document" use case.
Page 47
Requirements for Checkout Controller Functionality
Processes that the controller should handle.
Page 48
Conventional Design Issues
Common mistakes in assigning responsibilities.
Page 49
Problems with the Conventional Design
Highlighting the flaws of a procedural programming mindset in design.
Page 50
Applying The Expert Pattern
Responsibilities should align with the information expert.
Page 51
Expert Pattern in Action
Ensures request handling aligns with relevant object attributes.
Page 52
Expert Pattern Principles
Provides guidelines for assigning responsibilities during interactions.
Page 53
Applicability of the Expert Pattern
Update on how it fits within object interaction design.
Page 54
Benefits of The Expert Pattern
Advantages include low coupling and high cohesion.
Page 55
Class Exercise for Sequence Diagrams
Design a sequence diagram for user interactions in resetting a password.
Page 56
Problems with Reset Password Design
Misassignments in object responsibilities.
Page 57
Common Design Violations
Highlighting improper design methodologies.
Page 58
Correct Object Assignments Using Expert Pattern
Object attributes in context of requests being processed.
Page 59
The Creator Pattern
Introduction focused on responsibility for object creation.
Page 60
Implementing The Creator Pattern
Guidelines for choosing creators based on association.
Page 61
Understanding the Creator Pattern
Questions about who should create various objects.
Page 62
Benefits of The Creator Pattern
Discussing the advantage of low coupling in design.
Page 63
Transition to Chapter 9
Key Takeaway Points
Overview of Object Interaction Modeling domain.
Page 64
OIM Benefits
Helps develop understanding of business processes.
Page 65
OIM Steps and Overview
Steps from requirements gathering to design outputs.
Page 66
Object Interaction Focus
Distinguishing between foreground and background processing.
Page 67
Modeling Interactions
Importance of object interaction modeling and scenario descriptions.
Page 68
Steps for Object Interaction Modeling
Collect information.
Describe scenarios. ...
Page 69
Detailed Steps for Interaction Modeling
Nontrivial steps and identifying scenarios.
Page 70
Identifying Nontrivial Steps
Guidelines for distinguishing trivial vs nontrivial steps.
Page 71
Checkout Document Example
Analysis of user interactions in a library system.
Page 72
Scenario Tables
Understanding structure and utility of scenario tables.
Page 73
Scenario Description Example
Steps detailed in message interaction flows.
Page 74
Past Scenario Construction Guidelines
Tips for effective scenario writing and diagramming.
Page 75
Sequence Diagram Notions
Definitions for notations used in sequence diagrams.
Page 76
From Scenario Tables to Sequence Diagrams
Methodologies for translating scenarios.
Page 77
Sequential Processing Examples
How interactions are processed and represented.
Page 78
Additional Notations in Sequential Processing
Further elaboration on notation usage.
Page 79
Cases for Sequence Diagrams
Distinct scenarios and their processing meanings.
Page 80
Special Cases in Sequence Diagrams
Elaborates how to document similar subjects.
Page 81
Differentiating Analysis and Design
Clarifying boundaries in modeling and decision-making.
Page 82
Example Sequence Diagram - Manual System
Real-world object interactions highlighted in the library system.
Page 83
Analysis/Informal Sequence Diagram
Example interactions showcasing analysis techniques.
Page 84
From Analysis to Design
Transitioning from analysis diagrams to design representations.
Page 85
Flow of Control in Sequence Diagram
Detailed explanation of sequence execution flow.
Page 86
Analysis Sequence Diagram Representation
Visualizing current operations within a library system.
Page 87
Design Sequence Diagram Contrast
Distinctions between analysis and design flow in sequence.
Page 88
Representing Object Instances
Guidelines for showing instances in design diagrams.
Page 89
Implementation from SD to Code
Bridging sequence diagrams and final code execution.
Page 90
Color-Coding in Sequence to Code Translation
Importance of clarity and accessibility in coding.
Page 91
Common Mistakes in Object Interactions
Lessons learned from professional analysis.
Page 92
Sequential Function Call Mistakes
Observations on execution and function calling in practices.
Page 93
User Interaction Design Decisions
Clarifying the process order and event triggers.
Page 94
Review Checklist for Interaction Modeling
Importance of structured reviews for model quality assurance.
Page 95
Agile Principles in Practice
Encouraging collaborative construction of scenarios and tables.
NoteStudied by 7 peopleNoteStudied by 13 peopleNoteStudied by 14 peopleNoteStudied by 3 peopleNoteStudied by 7 peopleNoteStudied by 8 people