SADT & IDEF0 for Augmenting UML, Algile & Usability Engineering

Domain Modeling
Augmenting UML, Agile & Usability Engineering..

Welcome! David A. Marca
6th International Conference University of Phoenix
Software and Data Technologies
ICSOFT 2011, Seville, Spain, 18-21 July
College of IS&T
Phoenix, Arizona U.S.A.
dmarca@email.phoenix.edu

References list is given in last three sides. July, 2011

©OpenProcess, Inc. Do not copy. Do not distribute. Domain Modeling – A Lost Art, 1

Domain Modeling

OUTLINE
• What Methods?
• Why SADT/IDEF0? David A. Marca
• Which Features? University of Phoenix
• How to Augment? College of IS&T
• Knowledge Acquisition Phoenix, Arizona U.S.A.
• Closing Remarks dmarca@email.phoenix.edu

July, 2011

When to Augment Documentation is Abstract

Proposed by Project Sponsor. Specified in Project Request. Designed by Systems Analyst.

Produced by Programmers. Installed at User site. What User wanted.


When to Augment Over–Management = Waste

Over–specification:
• Rationale (context)
• Need (requirements)
• Solution (system)

Over–management:
• Goals (scope, time, $)
• Project (coordination)
• Results (system)


When to Augment Eliminate risk and waste!

“We are uncovering better ways
Over–specification: of developing software by doing it
and helping others do it. Through
• Rationale (context) this work we have come to value:

• Need (requirements) Individuals and interactions
over processes and tools.
• Solution (system)
Working software over
comprehensive documentation.

Customer collaboration
Over–management: over contract negotiation.
• Goals (scope, time, $) Responding to change
• Project (coordination) over following a plan.

• Results (system) That is, while there is value in the
items on the right, we value the
items on the left more.”

When to Augment Critical Thinking is Needed...

YES! … Agile NO! … Methods

Users fully understand & can
Heavy User Involvement Domain Modeling
articulate the entire domain?

Developers fully understand
Less Formal Settings Domain Modeling
entire problem & its context?

Users fully agree on the totality
Small Subset of Users Specify Requirements
of what exactly is needed?
Developers understand the
Notes & Sketches Specify Designs
totality of what is needed?
Intended technology is robust &
Ready-to-Go Technology Validate Assumptions
developers have experience?
Solution size/complexity can be
Rapid Prototyping Project Management
built within time/cost?
Management is aligned & has
Real-Time Changes Formal Change Control
no hidden agendas?





no hidden agendas?

Domain Modeling

OUTLINE
• What Methods?
• A Good Framework David A. Marca
• Agile System Development University of Phoenix
• Usability Engineering (UE) College of IS&T
• Unified Modeling Language Phoenix, Arizona U.S.A.
• The Framework’s Process dmarca@email.phoenix.edu
• Domain Size & Complexity?
• Why SADT/IDEF0?
• Which Features?
• How to Augment?
• Knowledge Acquisition July, 2011

Methods A good system development framework:

Unified Modeling
Language

Usability
Engineering

Agile
Methods


Methods Agile focus = the total system.

Unified Modeling
Language

Usability
Engineering

Develop & Agile
System Deploy Fast Methods


Methods UE focus = the total system use.

Unified Modeling
Language

Verify Usability
Usage Usability Engineering

Develop & Agile


Methods UML focus = the total system operation.

Define Unified Modeling
Specification Operation Language

Verify Usability

Develop & Agile


Methods All methods analyze the domain a little.

Domain


Verify Usability

Develop & Agile


Methods But the whole domain is much bigger!

Domain

Verify Usability

Develop & Agile


Methods Complex domain strong analysis tool...

Understand SADT/
Domain Environment IDEF0


Verify Usability

Develop & Agile


Methods Easy-to-understand domain & system…

Notes & Sketches
Explicit
Knowledge Final
System
Agile
Development

Collaborations


Methods If only the GUI is complex, then add...

UE

Notes & Sketches Evaluation Criteria
Explicit
Knowledge Prototype Final
System System
Agile Usability
Development Evaluation

Collaborations Shortcomings


Methods If data/functions are complex, then add...

UML UE
Business
Model

Specifications Evaluation Criteria
Explicit
System System
Agile Usability



Methods Large, complex, or difficult domain?...

SADT/IDEF0 Language Beliefs Assumptions Organization
Work Tasks Tools System Usage Expectations

UML UE
Business
Model

Explicit
System System
Agile Usability



Methods Users must ponder their assumptions?…

SADT/IDEF0 Language Beliefs Assumptions Organization
Work Tasks Tools System Usage Expectations

UML UE
Business
Model
Deep
Knowledge
Tacit
System System
Author/Reader Agile Usability
Cycle Development Evaluation


HCI Learnings


Domain Modeling

OUTLINE
• What Methods?
• History University of Phoenix
• Capabilities College of IS&T
• Unique Concepts Phoenix, Arizona U.S.A.
• Features dmarca@email.phoenix.edu
• Which Features?
• How to Augment?
• Knowledge Acquisition
• Closing Remarks
July, 2011

Why SADT/IDEF0? Long History of Use
1973 – developed
for general purpose
systems modeling.

1981 – USAF
commissions part
of SADT for sheet
metal fabrication.

1990 – IDEF0
becomes a widely
used standard.

2008 – USAF retires
use of IDEF0.


Why SADT/IDEF0? Many analysis capabilities
1973 – developed Extremely strong for:
for general purpose • Domain understanding
systems modeling.
• Problem identification
1981 – USAF • Solution boundary
commissions part
of SADT for sheet • Context preservation
metal fabrication. • Function reuse
• Operating scenarios
1990 – IDEF0
becomes a widely • External events
used standard. • Responses (to events)

2008 – USAF retires • Object identification
use of IDEF0. • Object encapsulation
• Asynchronous review


Why SADT/IDEF0? Unique modeling ideas
1973 – developed Extremely strong for: Unique concepts:
for general purpose • Domain understanding • General systems theory
systems modeling.
• Problem identification • Function–Data Duality
1981 – USAF • Solution boundary • Control versus Input
commissions part
of SADT for sheet • Context preservation • Decomposition Context
metal fabrication. • Function reuse • Small, Focused Models
• Operating scenarios • Author/Reader Cycle
1990 – IDEF0
becomes a widely • External events
used standard. • Responses (to events)
2008 – USAF retires • Object identification
use of IDEF0. • Object encapsulation
• Asynchronous review


SADT/IDEF0 SADT “Features” (1977)
Context
Feedback
Arrow
Pipeline
Transform
Control Tunnel
Means To/From All
Verbs Note
Nouns Footnote
Path Meta-Note
Dominance
Squiggle
Relevance
Sequence
Omissions
Node
Branches Model
Joins Interface
To-From
Reference
OR
Dominance
AND
Boundary Description
Parent Highlights
ICOM Glossary
Index
Calls


Domain Modeling

OUTLINE
• What Methods?
• General Systems College of IS&T
• Function–Data Duality Phoenix, Arizona U.S.A.
• Control versus Input dmarca@email.phoenix.edu
• Decomposition Context
• Small, Focused Models
• How to Augment?
• Closing Remarks July, 2011

General Systems Definition

Transdisciplinary
study of systems;

Discovering and
defining principles;

Can be applied
to all systems

and

associated fields
of R&D and
application.


General Systems Brief History

Transdisciplinary 1940s – 1950s
study of systems; • Cognitive Science
• Wiener's Cybernetics
Discovering and • Society was Formed
defining principles; • Ashby's Cybernetics
.

1960s – 1970s
Can be applied
• Bertalanffy's G.S.T.
to all systems
• Second-order Logic
• Catastrophe Theory
and .

1980s – 1990s
associated fields • Chaos Theory
of R&D and • Context Theory
application. • Adaptive Systems


General Systems Some Application Areas

Transdisciplinary 1940s – 1950s • Galactic
study of systems; • Cognitive Science • Planetary
• Wiener's Cybernetics • Biological
Discovering and • Society was Formed .

defining principles; • Ashby's Cybernetics • Power
. • Electrical
1960s – 1970s • Water
Can be applied
• Bertalanffy's G.S.T. .
to all systems • Economic
• Second-order Logic
• Catastrophe Theory • Government
and .
• Judicial
1980s – 1990s .
associated fields • Chaos Theory • Commerce
of R&D and • Context Theory • Manufacturing
application. • Adaptive Systems • Software


General Systems Modeling Examples …

Any kind of system
can be modeled .
using SADT/IDEF0

. .


General Systems Training Model

.

. .


General Systems Operations Model

. .


General Systems Manufacturing Model

.


General Systems Finance Model


Domain Modeling

OUTLINE
• What Methods?
• How to Augment?

Function-Data Duality Box = Function OR Data
FUNCTION DATA

Function Data


Function-Data Duality Box Interface = Data
FUNCTION DATA

Data

Data Data
Function Data

Realization


Function-Data Duality Box Interface = Function
FUNCTION DATA

Function

Function Function
Function Data

Realization


Function-Data Duality Same Language for Both
FUNCTION DATA

Data Function

Data Data Function Function
Function Data

Realization Realization


Domain Modeling

OUTLINE
• What Methods?
• How to Augment?

Control versus Input Box Sides = Semantics
FUNCTION DATA

Data Function

Data Data Function Function
Function Data

Realization Realization


Control versus Input Function Interface = ICOM
FUNCTION .

Control

Input Output
Function

Mechanism


Control versus Input Example …
FUNCTION .

Control What goes here?

Input Output Food Dish
Function Cook

Mechanism Stove,
Utensils


Control versus Input Example …
FUNCTION .

Control Recipe

Input Output Food Dish
Function Cook

Mechanism Stove,
Utensils


Control versus Input Data Interface = CRUD
. DATA

Create,
Delete

Update Read
Data

Store


Control versus Input CRUD invented in 1973
. DATA

Create,
Delete

Update Read
Data

Store


Domain Modeling

OUTLINE
• What Methods?
• How to Augment?

Decomposition in Context Make a Boundary

Build
Special
Part


Decomposition in Context Define the Interface

Build
Special
Part


Decomposition in Context Add ICOM Codes

C1 C2

I1
Build O1

I2 Special
Part O2

M1

Decomposition in Context Carry Forward…

C1 C2

I1 O1

I2

O2

M1

Decomposition in Context …Now Decompose

C1 C2

I1 O1

I2

O2

M1

Decomposition in Context The Final Diagram


Domain Modeling

OUTLINE
• What Methods?
• How to Augment?

Small, Focused Models Highly Specific Purposes


Small, Focused Models Distinct Subjects…

Subject Boat


Small, Focused Models Distinct Subjects…
Mode-Based Descriptions
Subject Boat


Small, Focused Models Real-World Scenarios…

Subject Boat Threat

Scenario CBDR


Small, Focused Models Real-World Scenarios…
2+ Subjects Interacting
Subject Boat Threat

Scenario CBDR


Small, Focused Models Behavior within Scenario

Subject Boat Threat

Scenario CBDR

Behavior Defend


Small, Focused Models Behavior within Scenario
State-Based Descriptions
Subject Boat Threat

Scenario CBDR

Behavior Defend


Small, Focused Models Common Functions …

Subject Boat Threat

Scenario CBDR

Behavior Defend

Function Maneuver Attack


Small, Focused Models Used in Multiple Models

Subject Boat Threat Weapon CM

Scenario CBDR

Behavior Defend



Small, Focused Models … Call / Support Notation


Scenario CBDR

Behavior Defend



Small, Focused Models This is analogous to…


Scenario CBDR

Behavior Defend



Small, Focused Models Object-Oriented Methods

Subject Boat Threat Weapon CM Object

Scenario CBDR Event

Behavior Defend Response

Function Maneuver Attack Subroutine


Small, Focused Models System within a Context


Scenario CBDR

Behavior Defend

Emergency
Preset


Domain Modeling

OUTLINE
• What Methods?
• Annotations Phoenix, Arizona U.S.A.
• UML dmarca@email.phoenix.edu
• Ethnography
• Usability Engineering
• Agile Development

Annotations A Unified Set of Supplements …

Glossary Diagram Text

Highlight

Activation


Annotations 1. Choose a Diagram …


Highlight

Activation


Annotations 2. … and its Glossary Page


Highlight

Activation


Annotations 3. Write Text Page (in context)


Highlight

Activation


Annotations 4. Highlight Diagram Scenario


Highlight

Activation


Annotations 5. Specify Activation Rules …


Highlight

Activation


Annotations How to Specify Activation Rules

Blueprint
C1
Machine Selected
on Floor Pick Machine
I1 Machine 1 O1

R1: 1I1 + 1C1 1O1


Domain Modeling

OUTLINE
• What Methods?
• Ethnography

UML: Objects Rules Interactions Aspects

Glossary-3 Diagram-3 Text-3

Highlight-3
Highlight-2
Highlight-1

Activation-
3
Activation-
2
Activation-
1


1. Glossary Objects, Classes, Relationships

Object,
Class, 1
Relationship

Highlight-3
Highlight-2
Highlight-1

Activation-
3
Activation-
2
Activation-
1


2. Activations Types, Roles, Interfaces

Object,
Class, 1
Relationship

Highlight-3
Highlight-2
Highlight-1

Activation-
3
Activation-
Types, Roles, 2 2
Activation-
Interfaces
1


3. Activations Business Rules & Events

Object,
Class, 1
Relationship

Highlight-3
Highlight-2
Highlight-1

Activation-
3
Activation-
Types, Roles, 2 2 3 Business
Activation-
Interfaces Rule / Event
1


4. Highlights Use Cases Interaction Diagrams

Object,
Class, 1
Relationship

4
Highlight-3 Use Case &
Highlight-2 Interaction

Highlight-1

Activation-
3
Activation-
Activation-
1


5. Objects + Uses + Interactions Activity Diagrams
5 Activity Diagram 5

Object,
Class, 1
Relationship

4

Highlight-1

Activation-
3
Activation-
Activation-
1


6. Objects + Activity Diagrams State Machines
& State Machine
6
Object,
Class, 1
Relationship

4

Highlight-1

Activation-
3
Activation-
Activation-
1


7. Calls & Supports Aspects (cross-cutting)
& State Machine
6 7
Object,
Class, 1 Aspect
Relationship

4

Highlight-1

Activation-
3
Activation-
Activation-
1


Correspondence with prior augmentation research
& State Machine
6 7
Object,
Class, 1 Aspect
Relationship
Domain General Formal
Ontology background descriptions of
Glossary-2
Database Diagram-2
knowledge base Text-2
the domain
(Brockmans’06)
Glossary-1 with reasoning
Diagram-1 (Bryant’03)
Text-1
logic (Süß’04),

4
HowHighlight-3
and why Use Case &
people do the Interaction
Highlight-2
work that they do
Highlight-1
(Larsen’99),

In-context:
Activation-
● business rules
3
Activation-
Types, Roles, (Skersys’05)
2 Business
2 3
Interfaces ● Activation-
decision-making Rule / Event
1
rules (Kestutis’09)


Domain Modeling

OUTLINE
• What Methods?
• UML Example dmarca@email.phoenix.edu
• Ethnography

Example SADT/IDEF0 UML Mapping
SADT/IDEF0 UML
(activity diagram) (activity diagram)

Function / Activity Box Lozenge

Data Arrow Arrow

Context Arrow,
State Circle
Property Label

Data Split & Join Arrow Intersection Bar

Control Flow Control Output X

Work Flow Input Output Solid Line

Rational Unified
Knowledge Acquisition Author / Reader Cycle
Process

Example SADT/IDEF0 Activity Diagram …


Example … Corresponding UML Activity Diagram
Job
Note how neat and uncluttered Plan Job
this diagram looks…you can Status
Evaluate Job Progress
easily see how:
Next
Yes
1) Next Step governs all of the Step Finished?
steps involved with machining.
No
2) Machining Result feeds Pick Tools
back to Evaluate Job Progress.
Machines
3) Ready Machine Place must
& Tools
happen before the Machine &
Assemble step can begin.
Setup Machining Place
Neatness and clarity happen
Materials Ready
because you did all the hard Machine
analytical thinking using the Place
SADT/IDEF0 methodology.
Machine & Assemble
Machining Result Finished Job


Example Generating a UML Activity Model
1. Swim Lanes
A. Create an SADT/IDEF0 model.
B. Decompose until one mechanism = one role.
C. Use these mechanism arrows to create swim lanes.
.

2. Activities
A. Decompose the SADT/IDEF0 model until purpose is met.
B. Make an SADT/IDEF0 schematic of a set of diagrams.
C. Add activities to swim lanes from the diagrams.
.

3. States
A. Add property labels (how often/fast/much/well) to arrows.
B. Context arrows start/end states. Properties other states.
C. Attach states to activities in each lane.
.

4. Flows & Messages
A. Add annotations to define scenarios.
B. Use input & output arrows to create object flows.
C. Use control arrows to create messages.


Example Mechanism Arrows Swim Lanes Step 1


Example Boxes Activities Step 2

Machinist Request
Approval
Kit
Plans
Estimates

Part

Status
Materials
Standards

Machines & Tools

Job
Scrap

Job

Example Context Arrows States Step 3

Machinist Request
Approval
Kit
Plans
Estimates

Part

Status
Materials
Standards

Machines & Tools

Job
Scrap

Job

Example Controls Arrows Control Flow Step 4


Example Input & Output Arrows Work Flow Step 5


Example Mechanism Arrows Swim Lanes Step 1

Build Special Part
Manage Job
Foreman
Complete Kit
Machinist
Inspect Job
Inspector


Example Boxes Activities Step 2

Build Special Part
Manage Job
Foreman

Receive & Review Kit Estimate Monitor Complete
Assign & Plan Job Job Work Job
Complete Kit
Machinist

Evaluate Pick Setup Machine &
Progress Tools Machining Assemble
Inspect Job
Inspector

Measure Appraise Accept or
Assess Stage
Dimensions Work Reject


Step
Example Context Arrows States 3a

Build Special Part
Machinist Request
Manage Job
Foreman


Estimates
Kit
Materials
Complete Kit
Machinist

Part
Tools Machines

Standards
Inspect Job
Inspector

Assess Stage
Approval


Example Properties Other States Step 3b

Build Special Part
Machinist Request
Manage Job
Foreman


Estimates
Kit
Materials
Complete Kit
Machinist

Ready Part
Place
Tools Machines

Standards
Inspect Job
Inspector

Assess Stage
Approval


Example Controls Arrows Control Flow Step 4

Build Special Part
Machinist Request
Manage Job
Foreman

Plans Status Estimates
Kit
Materials
Complete Kit
Machinist

Ready Part
Place
Tools Machines

Standards
Inspect Job
Inspector

Assess Stage
Approval


Example Input & Output Arrows Work Flow Step 5

Build Special Part
Machinist Request
Manage Job
Foreman

Plans Status Estimates
Kit
Materials
Complete Kit

Job
Machinist

Ready Part
Place
Tools Machines

Standards Scrap
Inspect Job
Inspector

Assess Measure Appraise Accept or
Stage Dimensions Work Reject
Approval


Domain Modeling

OUTLINE
• What Methods?
• Ethnography

Language Assumptions Norms “Work”
3 The
Work
2
Work 7 Aspect
Artifact

1 2
Native Glossary-2 Diagram-2 Text-2 Field
Language Glossary-1 Diagram-1 Text-1 Notes

Traditions Highlight-3
4
Fundamental Highlight-2
Assumption Highlight-1
Coupling & Cohesion
5 Pathology

Activation-
6 3
Activation-
Cultural 2
Activation-
Norms
1


Domain Modeling

OUTLINE
• What Methods?
• BPML dmarca@email.phoenix.edu
• Ethnography

Rules Aspects Use Cases HCI Model
3 The
Work
2
Work 7 Aspect
Artifact

1 2

Traditions Highlight-3 Use
4
Highlight-2 Case
Fundamental
Assumption 8
Highlight-1
Coupling & Cohesion
5 9 HCI
Pathology
Model
Activation-
6 3 6
Activation-
Cultural 2 Business
Activation-
Norms Rule / Event
1


3 The
Work
2
Work 7 Aspect
Artifact

Information: note
Glossary-3 Domain model
Diagram-3 Patterns that
Text-3
1 how it differs from syntax/semantics unify aspects 2
context-to-context for consistency of usage by via
(Najar’09) across models a set of themes
(Medvidovic’99) (Baniassad’04)

Context-based UI
Highlight-3 Use
4 Traditions
navigation space Case
Fundamental Highlight-2
& UI presentation 8
Assumption Highlight-1
Coupling & Cohesion models (Koch’01)
5 9 HCI
Pathology
Model
UI design trade-offs via patterns (Abraham’09).
Activation-
6 In-context problem-solution pairs (Abraham’09).
3 6
Activation-
Cultural Claims library for UI design reuse (Wahid, 2006).
2 Business
Activation-
Norms Rule / Event
1


Domain Modeling

OUTLINE
• What Methods?
• BPML dmarca@email.phoenix.edu
• Ethnography

Diagrams Notes + Sketches + Comments in Code
Workflow
Notes/Sketch
3 1
DB Object
Subroutine
& Relation
6
Glossary-2 Diagram-2 Text-2 Header / Block
Glossary-1 Diagram-1 Text-1 Comment
7

Highlight-3 System Use
Highlight-2 Notes/Sketch
2
Highlight-1

GUI
Prototype
Activation- 5
3
Activation-
2 Rule as
Activation-
RPC Code
1
4


Workflow
Notes/Sketch
3 1
DB Object
Subroutine
& Relation
6
Make & keep
Glossary-3 Document the
Diagram-3 Publish vital
Text-3
fixed the major knowledge of documentation
Glossary-2 Diagram-2 Text-2 Header / Block
object decisions domain & user’s in the prototype
Glossary-1 Diagram-1 Text-1 Comment
(Reifer’03) self-reflection (Warstaa’03) 7
(Wells’02) (Friedrich’07)

Document tacit
Highlight-3 System Use
assumptions Notes/Sketch
Highlight-2
(Dingsøyr’02) & 2
Highlight-1
self-reflection
(Salo’04)
GUI
Prototype
Document design
Activation- 5
knowledge with
3
Activation-
specifications
2 Rule as
Activation-
(Scacchi’02) & RPC Code
1
tools (Bryant’06) 4


Domain Modeling

OUTLINE
• What Methods?
• Knowledge Acquisition Phoenix, Arizona U.S.A.
• Closing Remarks dmarca@email.phoenix.edu

July, 2011

Domain Modeling

CLOSING REMARKS

1. Lack of explicit understanding or agreement?

2. Analyze the context of the “context” (the context around
event-response, problem-solution, system usage).

3. Use a general purpose domain modeling methodology.

4. Create descriptions that augment UML, UE, agile.

5. “Be agile with agile.” (Francisco Rebella de Andrade)

Domain Modeling

CLOSING REMARKS


2. Analyze the context of the “context” (the context around
event-response, problem-solution, system usage).




Domain Modeling

CLOSING REMARKS


2. Know the context of the “context” (the context around
event-response, problem-solution, system usage)?




Domain Modeling

CLOSING REMARKS






SADT & IDEF0 for Augmenting UML, Algile & Usability Engineering

SADT & IDEF0 for Augmenting UML, Algile & Usability Engineering

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (17)

Similar a SADT & IDEF0 for Augmenting UML, Algile & Usability Engineering

Similar a SADT & IDEF0 for Augmenting UML, Algile & Usability Engineering (20)

Último

Último (20)

SADT & IDEF0 for Augmenting UML, Algile & Usability Engineering