System Design

1
System Design
2
Logical Architecture Package Diagrams

• large scale organization of the software classes
  into packages, subsystems, and layers
• may use package diagrams to show the logical
  architecture as part of the design model
• input come from the Supplementary Specification
• examples on p. 198 199

3
Logical Architecture Layers

• layer is a very coarse grained grouping of
  classes, packages or subsystems
• show cohesive responsibility for a major aspect
  of the system
• higher layers call upon services of lower layers
• typically layered as
• user interface
• application logic domain objects
• technical services
• strict vs. relaxed layers
• we are focusing on the application logic layer

4
Software Architecture

• significant decisions about the organization of
  the system
• structural elements
• interfaces
• behaviors
• collaborations

5
Package Diagrams

• used to show logical architecture
• groups elements
• can show nesting and dependencies
• namespace fully qualified names

6
Design with Layers

• organize the large scale logical structure of a
  system into discrete, distinct layers
• collaboration coupling is from higher to lower
  only
• helps prevent
• tight coupling
• application logic mixed with user interface
• technical services mixed with applications
• example on p. 203

7
Guidelines

• cohesive responsibilities maintain a separation
  of concerns
• map code organization to layers and UML packages
• domain objects to represent a thing in the
  problem domain and has related business or
  application logic domain layer
• dont show external resources as the bottom layer
  dont confuse logical architecture with
  deployment
• model view separation

8
Model-View Separation Principle

• dont connect non-UI objects directly to UI
  objects
• dont put application logic in the UI objects
• UI objects should only initialize elements,
  receive UI events, and delegate requests for
  application logic to a non-UI object

9
Model-View Separation Principle 2

• supports cohesive model definitions that focus on
  the domain processes
• allow separate development of the model and view
• minimize the impact of requirement changes across
  the layers
• allow new views to be easily used
• allow multiple simultaneous views of the same
  model
• allow execution of the model independent of the
  view
• allow easy porting of the model to another view

10
SSDs, Systems Operations Layers

• objects in the UI layer capture the system
  operation requests
• these UI objects forward the requests to the
  domain layer
• messages sent from the UI object correspond to
  messages identified in the SDDs

11
Object Design

• code
• draw then code
• drawing overhead should be worth the effort
• only draw
• emphasize lightweight drawing in agile

12
Agile Modeling Lightweight UML

• reduce drawing overhead
• model to understand and communicate
• modeling with others
• create several models in parallel

13
UML Case Tools

• choose a tool to easily integrate with your IDE
• reverse engineering

14
How much UML?

• few hours to a day for a 3 week iteration
• sketching
• continually evolving the design
• spend significant time doing interaction diagrams
  along with the class diagrams!

15
Static Dynamic Modeling

• static
• class diagrams
• for class names, attributes, method names
• dynamic
• interaction diagram sequence and communication
• for the behavior of the system

16
Object Design Skill vs. UML Skill

• principles of responsibility assignment and
  design patterns are paramount
• drawing UML is trivial by comparison

17
CRC Cards

• Class Responsibilities Collaborations
• index cards containing the responsibilities and
  collaborations of a class
• CRC modeling session

18
Interaction Diagrams

• shows how objects interact via messages
• dynamic object modeling
• sequence communication

19
Sequence Diagrams

• shows interactions in a fence format

20
(No Transcript)
21
Communication Diagrams

• shows interactions in a graph or network format

22
Importance of Interaction Diagrams

• spend time doing dynamic object modeling with
  interaction diagrams, not just static object
  modeling with class diagrams
• the act of dynamic modeling is key

23
Interaction Diagram Notation

• basic message expression syntax
• return message (parm type) returnType
• singleton objects
• put a 1 in the top right hand corner of lifeline
  box

24
Sequence Diagram Notation

• lifeline boxes and lifelines
• found messages
• replies returns
• messages to self
• creation destruction of instances
• conditions looping
• messages to static methods
• polymorphic messages
• asynchronous synchronous
• filled arrows

25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
Communication Diagram Notation

• links
• messages
• messages to self
• creation and destruction of instances
• message number sequencing
• conditional messages
• mutually exclusive conditional paths
• looping
• messages to static methods
• polymorphic messages
• asynchronous synchronous

32
Class Diagrams

• shows classes, interfaces and their associations
• static object modeling

33
Class Diagram Notation

• classes
• interfaces
• attributes
• methods
• associations
• p. 250

34
Design Class Diagram Classifier

• DCD when a class diagram is used in a software
  or design perspective
• form part of the domain model
• classifier a model element that describes
  behavioral and structural features
• regular classes
• interfaces

35
Attributes

• attribute text
• association line with roles and navigability
• both
• p. 252
• visibility name type multiplicity default
  property_string
• assumed private by default

36
Notes, Constraints, Method Bodies

• comment/note - no semantic impact
• constraint must be enclosed in braces
• method body - implementation

37
Operations Methods

• visibility name (parameter list)
  property_string
• assumed public by default

38
Properties Property Strings

• a named value denoting a characteristic of an
  element
• may be represented in many ways

39
Generalization, Abstract Classes Operations

• UML notation arrow from subclass to superclass
• abstract tag on classes and operations
• final tag

40
Dependency

• a dashed arrow from the client to the supplier
• coupling
• having an attribute of the supplier type
• sending a message to a supplier
• receiving a parameter of the supplier type
• supplier is a superclass or interface

41
Interfaces

• different notation on p. 263
• dashed arrow for implements

42
Composition Aggregation

• composition whole is totally responsible for
  lifecycle of part, filled diamond
• use composition over aggregation
• no need to name the association

43
Constraints

• restriction or condition on a UML element
• may use OCL
• text between braces

44
Qualified Association

• association with a qualifier used to select an
  object from a larger set of related objects

45
Association Class

• can treat an association as a class itself

46
Singleton Class

• there is exactly one instance of this class in
  the entire system

47
Template Classes Interfaces

• templates, parameterized types, generics
• example on p. 268

48
User Defined Compartments

• predefined compartments
• user defined compartment

49
Active Class

• active object runs and controls its own thread of
  execution
• double vertical lines on the left and right of
  the class box in the class diagram

50
GRASP

• designing objects with responsibilities
• RDD
• General Responsibility Assignment Software
  Patterns

51
All 9 GRASP Principles

• Information Expert - A general principal of
  object design and responsibility assignment?
• Creator - Who creates?
• Controller - What first object beyond the UI
  layer receives and coordinates a system
  operation?
• Low Coupling - How to reduce the impact of
  change?
• High Cohesion - How to keep objects focused,
  understandable, and manageable?
• Polymorphism - Who is responsible when behavior
  varies by type?
• Pure Fabrication - Who is responsible when you
  are desperate, and do not want to violate high
  cohesion and low coupling?
• Indirection - How to assign responsibilities to
  avoid direct coupling?
• Protected Variations - How to assign
  responsibilities so that the variations or
  instability in the elements do not have an
  undesirable impact on other elements?

52
UML vs. Design Principles

• UML is just a visualization tool
• good OO design is a mind skill

53
Object Design

• inputs to object design
• requirements workshop
• some of the use cases
• programming experiments
• use case text
• system sequence diagram
• operation contracts
• outputs
• UML interaction, class, package diagrams
• UML sketches prototypes
• database models
• report sketches prototypes

54
Activities of Object Design

• coding
• testing
• modeling

55
Responsibilities RDD

• responsibilities, roles, and collaborations
• doing knowing
• can apply at any scale of software

56
GRASP

• a methodical approach to RDD
• guiding choices about assigning responsibilities

57
Responsibilities, GRASP UML Diagrams

• think about assigning responsibilities while
  modeling
• modeling considers these responsibilities

58
Patterns

• principles and idioms for solving a common
  problem in a common way
• description of a problem and a solution that can
  be applied to new contexts

59
GRASP -gt Object Design

• GRASP is 9 principles in OO design
• not trying to redefine patterns

60
Creator

• Assign class B the responsibility of creating an
  instance of class A if
• B aggregates A objects.
• B contains A objects.
• B records instances of A objects.
• B closely uses A objects.
• B has the initializaing data that will be passed
  to the A object when it is created.
• aggregation
• A kind of association used to model whole-part
  relationships between things.

61
(No Transcript)
62
Information Expert

• Pattern Name Information Expert
• Problem  What is a basic principle by which to
  assign responsibilities to Objects?
• Solution Assign a responsibility to the class
  that has the information needed to fulfill it.

63
Low Coupling

• coupling
• how strongly one element is connected to, has
  knowledge of, or relies on other elements

64
Controller

• Assign the responsibility for receiving or
  handling a system event message to a class that
• Represents the overall system, device, or
  subsystem.
• Represents a use case scenario in which the
  system event occurs.
• system event
• An event generated by an external actor.
• system operation
• An operation of the system in response to a
  system event.
• controller
• A non-user interface object responsible for
  receiving or handling a system event, and that
  defines the method for the system operation.

65
High Cohesion

• cohesion
• how strongly related and focused the
  responsibilities of an element are

66
Use Case Realization

• Ch. 18

67
Artifacts Comments
68
Iterative Evolutionary Object Design
69
Visibility

• Ch. 19

70
Visibility Between Objects
71
GRASP Responsibilities
72
Polymorphism
73
Pure Fabrication
74
Indirection
75
Protected Variables
76
GoF Design Patterns Intro
77
UML Activity Diagrams Modeling
78
How to Apply Activity Diagrams
79
Activity Diagram Notation
80
Activity Diagram in UP
81
UML State Machine Diagrams Modeling
82
Events, States, Transitions
83
How to Apply State Machine Diagrams
84
State Machine Diagram Notation
85
State Machine Diagram in UP
86
Architectural Analysis
87
When to do Architectural Analysis
88
Variation Evolution Points
89
Architectural Analysis
90
Common Steps
91
Identification Analysis of Architectural Factors
92
Resolution of Architectural Factors
93
Themes
94
Iterative Architecture in UP
95
Logical Architecture Refinement
96
Collaboration with Layers Pattern
97
Other Layer Pattern Issues
98
Model-View Separation
99
Package Design