Chap. 7: Structured Modeling

focus on data and process efficiency

class: general template use to create instances of objects

concrete: creates objects

abstract: don't

attribute: pieces of data associated with a class

derived attributes: can be calculated or derived

operation: actions taken/ behavior of a class

constructor: creates object

query: retrieves information on object state

update: changes values of some or all attributes

relationships

generalization: enables inheritance (is a kind of)

aggregation: parts of a whole (part of, member of...)

association: weak aggr., association between classes

CRC Cards: Class-Responsibility-Collaboration

knowing responsibility: what a class can know

doing responsibility: what a class can do

collaboration: contracts between clients and servers

client: sends a request to another class

server: receives a request

contract: formal interaction between c&s

anthropomorphism:: classes are human

role-play: Humans pretend to be classes, add detail

elements: name of class (noun), ID, type, description,

responsibilities, collaborators, attributes, relationships

textual analysis: analyze use-case description

common noun: class, proper noun: object, adjective:

attribute, doing verb: operation, being verb:

classification, having verb: aggr/association,

transitive: operation, intransitive: exception,

verb phrase: operation, adverb: attribute

common object list: lists objects common to business

tangible things: within business domain

incidents: events that occur

interaction: transaction that occurs

pattern: useful group of collaborating classes

creation process: CRC cards always updating

1. create CRC cards: use text analysis and SVDPI

(subject verb direct obj. preposition indirect obj.)

2. examine common objects list

3. role-play

4. create class diagram: transfer from CRC card

5. review class diagram

6. incorporate patterns

7. review model

class diagram: static model of classes and relationships

class fields: top name, mid attribute, bottom operations

visibility: level of information hiding

public (+) protected (#) private (-)

relationship: drawn by drawing line between classes

+ denotes roll not relationship

multiplicity: # of instances associated with object

relationship class: relationship has association

relationship drawn with rectangle and dashed line

generalization: one class inherits from another class

solid line from sub to super with hollow arrow

aggregation: one class comprised of other classes

diamond placed near class part of, solid line

simplification methods:

view: only classes/methods particular to use case or

a type of relationship or restricted information

packages: grouping classes together

object diagram: class diagram instantiated

Chap. 8: Behavior Modeling

dynamic aspects of an information system

(object collaboration, business process, effects of proc.)

messages: information sent to objects

interaction diagrams: focuses on object over class

sequence diagram: sequence of messages

illustrates objects participating and messages passed

actors and objects participate on top

lifeline: dotted line below obj./act.

temporary object: created by object, x denotes end

execution occurrence: thin box over lifeline

denoting classes are sending/receiving

message convey information between objects

operation call: solid line between two objects with

solid arrow head denoting how message is passed

return message: dashed line with arrow, omitted

unless it adds a lot of information to diagram

condition: must be met to send message [exists]

self-delegation: message to self

generic: all scenarios

instance: a scenario

building a sequence diagram

1. set the context

2. identify which objects will participate

3. set the lifeline for each object

4. add the messages to the diagram

5. place the execution occurrence

6. validate diagram

communication diagrams

similar to sequence, emphasize flow of messages

use actors and objects

cannot explicitly show object being created/deleted

association: undirect line

messages: labels on assocation ( LookUp () --> )

*: sent repeatedly

simplified by packages

building a communication diagram

1. set the context

2. identify objects and associations linking objects

objects participate in collaboration, not classes

CRUD matrix between objects

(create read update delete (only temporary obj))

3. lay out objects and associations

4. add messages between objects

5. validate diagram

behavioral state machines: object change state w/ time

state: value of attributes & relation w/ objects

depicted in rectangle with rounded corners

initial state: small solid filled in circle

final state: circle in circle

event: something that takes place to change values

transition: movement of object from state to state

guard condition: boolean allowing transition if true

action: atomic, nondecomposable process

activity: nonatomic decomposible process, interuptable

building a behavioral state machine

1. set the context

2. identify state object will have over time

3. determine the sequence

4. identify the events, actions, and guard conditions

trigger: cause an object to move from state to state

Chap. 9: Moving on to Design

a lot of "going back and forth" may occur between:

analysis phase: how to provide it

design phase: how to build it

^ possibility of successful and easily maintained system

combines functional, static, and dynamic views

plan, gather requirements, perform builds, get feedback

avoidable mistakes: long design time, feature creep

silver bullet syndrome, switching tools in mid-project

factoring: reducing modules into standalone modules

becomes generalization or aggregation

abstraction: identifies abstract or concrete classes

refinement: exact opposite

partition: OO Subsystem, decompose larger system

good place to find partitions are collaboration models

CRUD matrix are good too

also client/server/contract models

"the more messages sent between objects, the more

likely they belong in the same partition."

layers: represents an element of the architecture

Model-View Controller architecture

models do implement application logic

views (out) and controllers (in) do user interface

foundation: contains classes needed for OO

physical architecture: software on hardware

human computer interaction: view and controller

data management: issues involving persistent data

problem domain: everything we've gone over before

package: general construct applied to UML

simplifies UML and shows dependency relationships

package diagram: object diagram w/ packages

symbol for package is tabbed folder

dependency relationship: dashed arrow

modification dependency: a change in one

package could require a change in another

building a package diagram

1. set the context

2. cluster the classes based on relationships

3. place the clustered classes into packages

4. identify dependencies in relationships

5. place dependency relationships

design strategies

custom development: new system from scratch

+allows for meeting specialized requirements

+allows flexibility and creativity

+easier to change components

+builds personnel skills

-may tax firm’s resources

-may add significant risk

packaged development: already written

+may be more efficient

+may be more thoroughly tested and proven

+range from small to large components

-must accept functionality provided

-may require change in how the firm does business

-significant “customization” or “workarounds”

workarounds: addon programs, no vendor support

system integration: old new and packaged

object wrapper: wraps around legacy system

outsourcing::Hire external firm to write software

+may have more skills

+may extend existing resources

-never outsource what you don’t understand

-could lose confidential information

-carefully choose vendor

get a contract

time and agreement: whatever it takes

fixed-price: they absorb added costs

value-added: outsourcer gets x% profits

outsources like short term

how to choose: business need, in-house experience,

project skills needed, project management ability,

time frame allowed

alternative matrix: weighs pros and cons

request for proposal (RFP): solicits vendor proposals

request for information (RFI): shorter, less detailed

Chap. 10: Class and Method Design

encapsulation: combines processes into single object

information hiding: only required information visible

polymorphism: same messages trigger different objects

dynamic binding: late binding

inheritance: reusing previously defined classes

single inheritance: class has single parent

multiple inheritance: class has multiple parents

redefinition: redefine elements of a superclass

inheritance conflict: error by redefinition

most inheritance conflicts due to poor definition

coupling: how interrelated modules are in a system

interaction: relationships with methods and objects

inheritance coupling: generally desireable

no direct coupling (good): no relation amongst methods

data: method passes a variable to called methods

stamp: method passes a composite variable (object)

control: calling method passes variable controlling

execution of method

common or global: method refers to "global data area"

content or pathological (bad): object refers to another

cohesion: method/class should do one thing

method cohesion: hard understaing multiple functions

functional (good): performs one task

sequential: two functions in order

communicational: two functions use same attributes

procedural: multiple weakly related functions

temporal: multiple related functions in time

logical: different functions

coincidental (bad): totally different for no reason

class cohesion class should only have vital attributes

ideal (good):no mixed cohesion

mixed-role: attributes relate multiple objects

mixed-domain: relate objects on different layers

mixed-instance (bad): two distinctly different objects

connascence: two modules intertwined

minimize outside encapsulation, maximize inside

name: method attribute tied to name of attribute

type: attribute declaration change with attribute change

convention: range of values has semantic meaning

algorithm: two methods depend on same algorithm

position: order of code is critical.

additional specifications

1. ensure problem domain layer classes are necessary

2. finalize the visibility of the attributes and methods

3. decide on the signature of every method

4. define the constraints that must be preserved

violations are known as exceptions

chances for reuse

design patterns: commonly occurring groupings

whole-part aggregation/composition

command processor: interface from execution

forward-received: peer-to-peer architecture

framework: a set of implemented classes useable

class library:similar to ^, not domain specific

component: encapsulated software plugged in system

restructuring

factoring: seperate aspects into methods/classes

normalization: identify missing classes

only support generalization/specialization

optimizing design

1. review access paths between objects

2. review each attribute

3. review direct and indirect fan-out

4. execution order

5. avoid recomputing derived attributes

use a trigger

delay recomputation until next access

constraint: unit of a contract

pre-condition: constraint that must be met prior

post-condition: constraint that must be met after

invariants: constraints that must be true of all classes

elements of a contract:

method name, class name, id, clients, description

of responsibilities, arguments received, type of value

returned, pre-conditions, post-conditions

method specifications: description of methods on CRC

general information: method/class name, ID, contract

ID, programmer, due date, target language

events: list the events that trigger the method

message passing to and from the method

algorithm specifications

structured english

psuedocode

UML's activity diagram

2006-04-11T12:01:10