eamf applied9/18/2006 2 architectural analysis using eamf 5 september 15 2006 from requirements to...

9/18/2006

1

Understanding the EAMF Approach

Part I:Requirements Engineering

Requirements Model EngineeringBusiness Architecture Modeling

Architectural Analysis Using EAMF 2 September 15 2006

Learning Objectives

• Understand requirements engineering “ala” EAMF

• Command of requirements model engineering “ala” EAMF

• Ability to use EAMF to analyze and design business architectures


Topical Outline

In this presentation:• Traditional/Object-Oriented Architecture Analysis & Design Approach

• EAMF Architecture Analysis & Design Approach


Roadmap

Object Oriented Architecture Analysis & Design Approach• From Requirements to Analysis

• Analysis Class

• Use Case Realization

• Example: Pay Invoice Use Case

• Pay Invoice Use Case: Flow of Events

• Analysis Class Diagram Realizing a Pay Invoice Use Case

• Collaboration Diagram Realizing a Pay Invoice Use Case

• Analysis and Design Workflow

• Defining the Architecture

• Analysis and Design Roles, Activities, and Artifacts

9/18/2006

2


From Requirements to Analysis

• Requirements specify the behavior of the largest-grained component: the system– Specifies the behaviors the system provides for and

with the actors– “The system shall…”

• Object-oriented analysis is reduction of a system to a coarse set of discovered objects with responsibilities, so that the set of objects is able to fulfill the behavioral requirements of the user

• Analysis limits the effort to objects found in the domain –otherwise you are doing design


Analysis Class

• Analysis classes represent an early conceptual model for ‘things in the system which have responsibilities and behavior’

• Class, stereotyped as «boundary», «entity» or «control»– Entity classes

– Long-lived, real-life object or event in the application domain– Data and behavior– Usually persistent (saved in a file or database)

– Boundary classes– Interaction between the system and its actors– At the system boundary

– Control classes– Coordination and sequencing of system behavior– Transactions

Entity

Control

Boundary

Analysis Class


Collaboration diagram

Sequence diagram

Class diagram

GrpFile

read( )open( )create( )f illFile( )

rep

Repository

name : char * = 0

readDoc( )readFile( )

(from Persistence)

FileMgr

fetchDoc( )sortByName( )

DocumentList

add( )delete( )

Document

name : intdocid : intnumField : int

get( )open( )close( )read( )sortFileList( )create( )f illDocument( )

fList

1

FileList

add( )delete( )

1

File

read( )

read() f ill the code..

Use Cases

Use Case Use-Case Realization

• A use-case realization is a description of how a particular use case is realized within the design model, in terms of collaborating objects

<<trace>>

Use-Case Realization


Example: Pay Invoice Use Case

• The use case Pay Invoice is used by a Buyer to schedule invoice payments. The Pay Invoice use case then completes the payment on the due date

• Pre-condition: The Buyer has received the goods or services ordered and at least one invoice from the system. The Buyer now plans to schedule the invoice(s)

• Post-condition: The use-case ends when the invoice has been paid or the invoice payment was canceled and no money was transferred

9/18/2006

3


Pay Invoice Use Case: Flow of Events

• Primary Scenario (i.e., basic path)1. The buyer invokes the use case by beginning to browse the invoices received by

the system. The system checks that the content of each invoice is consistent with the order confirmations received earlier (as part of the Confirm Order use case) and somehow indicates this to the buyer. The order confirmation describes which items will be delivered, when, where, and at what price.

2. The buyer decides to schedule an invoice for payment by the bank, and the system generates a payment request to transfer money to the seller’s account. Note that a buyer may not schedule the same invoice for payment twice.

3. Later, if there is enough money in the buyer’s account, a payment transaction is made on the scheduled date. During the transaction, money is transferred from the buyer’s account to the seller’s account, as described by the abstract use case Perform Transactions (which is used by Pay Invoice). The buyer and the seller are notified of the result of the transaction. The bank collects a fee for the transaction, which is withdrawn from the buyer’s account by the system.

4. The use-case instance terminates


Order Confirmation

Buyer Payment Request UI

Order Handler

Invoice

Payment Scheduler Payment Request

Analysis Class Diagram Realizing a Pay Invoice Use Case


Scott : Buyer : Payment Request UI

: Order Handler

: Payment Scheduler : Payment Request

: Order Confirmation

: Invoice

1: Browse Invoice

6: Schedule Invoice for Payment

2: Browse

9: setStatus(scheduled)

3: Check Invoice

7: Schedule payment

4: Get

5: Get

8: New

Collaboration Diagram Realizing a Pay Invoice Use Case


Analysis and Design Workflow

9/18/2006

4


Summary: Architecture Engineering Steps

• Create an initial sketch of the architecture of the system

• Define an initial set of architecturally significant elements to be used as the basis for analysis– Issues that are typically architecturally significant include

performance, scaling, process and thread synchronization, and distribution

• Define an initial set of analysis mechanisms

• Define the initial layering and organization of the system

• Define the use-case realizations to be addressed in the current iteration

• Identify analysis classes from the architecturally significant use cases

• Update the use-case realizations with analysis class interactions


Summary: Architecture Engineering Steps (cont.)

• How to Staff– Small team with cross-functional team members– The team should include members with domain experience who

can identify key abstractions– The team should also have experience with model organization

and layering

• Work Guidelines– The work is best done in several sessions, perhaps performed

over a few days (or weeks and months for very large systems)– Iterate between Architectural Analysis and Use-Case Analysis


Summary: Architecture Engineering Steps (cont.)


Summary: Architecture Engineering Artifacts

9/18/2006

5


Roadmap

EAMF Architecture Analysis & Design Approach• Building Pattern Cluster Networks Using EAMF

• EAMF Methodology

• EAMF-Augmented Incremental/Iterative SDLC Used for ABS-B2

• ABS-B2’s Project Requirements Types and Enterprise Requirements Categories

• Requirements Traceability Graph

• Use of IBM Rational ReqPro for ABS-B2 Requirements Engineering Phase

• Building Pattern Cluster Networks Using EAMF

• EAMF Requirements Model Engineering

• etc.


Building Pattern Cluster Networks Using EAMF


EAMF Methodology

ManagementEnvironment

Enterprise Planning

Detailed AnalysisDetailed Design

High-Level Design

Preliminary Iteration(s)

Iter.#1

SDLC StagesDisciplines & Process Workflows

Iterations

Supporting Workflows

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Product Mapping

Administration

High-Level Analysis

Deployment

Planning Build/TestInitiation Tech Design Install/Close ROI Benefits

Iter.#m+2


EAMF-Augmented Iterative/Incremental SDLC Used for ABS-B2

9/18/2006

6


ABS-B2's Project Requirements Types and Enterprise Requirements Categories


Requirements Traceability Graph


Use of IBM Rational ReqPro for ABS-B2's Requirements Engineering Phase

Ente

rpris

e P

roje

ct R

equi

rem

ents

type

s ar

e th

e sa

me

as P

roje

ct R

equi

rem

ents

Typ

es

Enterprise Project D

ocuments types are the sam

e as Project D

ocuments Types


Building Pattern Cluster Networks Using EAMF

9/18/2006

7


EAMF Requirements Model Engineering

Traceable Artifacts


Requirements and Definitions Traceability Graph


Reasoning About Business Entities and Their Dependencies and Goals


Pattern Language Structure for Agent Patterns Selection

9/18/2006

8


Requirements Model Engineering Activities for ABS-B2

Document New Requirements

Traceability

Document Traceability

Between Modeling Constructs and

Req. Model Definitions

Map Business Requirements into

Requirements Model

<analysis input> Project

Requirements

Document Traceability

between Project Requirements and

Req. Model Definitions/

Requirements

Draw Actor and Dependency Diagram(s)

Draw Goal and Task Diagram(s)

Document Modeling

Constructs

Populate Requirements

Model Categories

Sparx Systems EA

EAMF CatalogSparxSystems EARepository ReqPro

Reqs Repository

Shared File System

<analysis input> R

equirements M

odel

Business Analyst Business Architect

1 2 3

4

5

ReqPro JUCMNav

ReqPro

<definition>all<requirement>some

Def(s) and Req(s)Traceability Info <requirement>

Business Entity

EAMF ProcessPatterns

EAMF ProcessPatterns

<requirement>Business Entity

<requirement>Business Entity

<requirement>Business Use Case

<requirement>Organizational<requirement>Location

6

7

8

Def

Req

Req

Modeling ConstructsTo Req. Model Defs

TraceabilityInformation

Legend:

1. ReqPro Doc(s)

2. ReqPro Req(s)

3. ReqPro Traceab. Info*

4. EA Doc Ref(s)*

5. EA Def(s)

6, EA Req(s)

7. EA Traceab. Info*

8. jUCMNav Diagram

9. EAMF Patterns

Def

Req

Def Req

Req

Req(s) Traceability Info


Use of Sparx Systems EA to Engineer the ABS-B2 EAMF Requirements Model

Project Bus. Vocabulary Definition

Strategy Definition

Concept Definition

Business Use Case Requirements

Business Model

Requirements

Requirements Definition

Project Requirements ModelCategories

RequirementsModel Engineering

Proj. Bus. Directives

Business Objective

Features and Events

Functional Requirements

Non-Functional Requirements

Business Entity Requirements

Business Process

Requirements

Bus/Workflow Rules Reqs

Process Model

Requirements

Location Requirements

Organizational Requirements

EAMF Catalogs and Enterprise Requirements Model Categories

Enterprise Glossary

Enterprise Business Rules

Enterprise Solution Patterns

Enterprise Strategies

Pattern/Product/Enterprise Solutions Catalog

Enterprise Projects (e.g., Ent. Worker Services)

<analysis input> Requirements ModelWithin EA EAMF- Compliant Project

Template

<definition> Project Business Vocabulary

<definition> Strategy Definition

<definition> Concept Definition

<requirement> Business Entity Requirements

<requirement> Business Use Case Requirements

<requirement> Business Model Requirements

<requirement> Requirements Definition

EAMF Pattern, Product and Enterprise Solutions Catalogs

EAMF Enterprise Requirements Model

Enterprise Projects(EAMF-Compliant)


Sparx Systems EA Template for ABS-B2


Use of IBM Rational ReqPro for ABS-B2's Requirements Model Engineering Phase

Ent

erpr

ise

Pro

ject

Req

s M

odel

type

s ar

e th

e sa

me

as P

roje

ct R

eqs

Mod

el T

ypes

Enterprise P

roject Req M

odel Docs types are the sam

e as Project R

eq Model D

ocs Types

9/18/2006

9


jUCMNav GRL Modeling Constructs


jUCMNav GRL Modeling Constructs (continued)


jUCMNav User Interface


Actor-Dependency Diagram for the ESLM Domain (Early Requirements Discipline)

9/18/2006

10


Goal Diagram for AFLAC Service Request Processor (Early Requirements Discipline)


Business Architecture Analysis Using EAMF

Software Development Lifecycle Phases

Traceable Artifacts


Strategy Definition

Concept Definition


Business Model

Requirements


Requirements ModelCategories



Business Objective

Features and Events




Business Process

Requirements


Process Model

Requirements




Enterprise Glossary






Relationships

Bus. Arch.

BUC Mdl

Entities

Bus. ProblemForce

Hierarchies

URN Mdl

Candidate Bus. Arch.

Styles

CandidateReferenceProjects

Req Mdl Analysis

Bus. Arch.Analysis Artifacts

Analysis

Org. Mdl

Loc. Mdl

Capab. Matrix

Candidate Bus Pattern Hierarchies


Pattern Language Structure for Agent Patterns Selection


UCM Notations Summarized

Figure 27

9/18/2006

11


UCM Notations Summarized (continued)


Inter-Scenario Relationships Design Patterns Used in EAMF’s BPM approach

Scenario Interactions

Scenario Aborting

Mutually Exclusive Scenarios

Scenario Composition

Waiting Place

Timed Waiting Place

Scenario Dependency

Inter-Scenario Relationships

Scenario Clustering

ConcurrentScenarios


Integration of Goal Oriented and Scenario-Based Modeling


Use of Sparx Systems EA to Analyze the ABS-B2 Business Architecture


Strategy Definition

Concept Definition


Business Model

Requirements





Business Objective

Features and Events




Business Process

Requirements


Process Model

Requirements




Enterprise Glossary






Relationships

Bus. Arch.

BUC Mdl

Entities

Bus. ProblemForce

Hierarchies

URN Mdl


Styles



Analysis

Org. Mdl

Loc. Mdl

Capab. Matrix


<analysis input> Requirements ModelWithin EA EAMF- Compliant Project

Template

<definition> Business Vocbulary

<definition> Strategy Definition

<definition> Concept Definition

<requirement> Business Entity Requirements

<requirement> Business Use Case Requirements

<requirement> Business Model Requirements

<requirement> Requirements Definition

<view> Analysis within <perspective> Business Architecture of EAMF-

Compliant Project Template

EAMF Pattern, Product and Enterprise Solutions Catalogs

EAMF Enterprise Requirements Model

Enterprise EAMF-Compliant Project

Within EAMF Framework

Within EAMF Enterprise Solutions Catalog

9/18/2006

12


Business Architecture Design Using EAMF

Software Development Lifecycle PhasesDesign

Relationships

Bus. Arch. Engineering

BUC Mdl

Domain ModelEntities

Bus. ProblemForce

Hierarchies

URN Mdl


Styles



Bus. Arch.Design Artifacts

Analysis

Org. Mdl

Loc. Mdl

BUC Mdl

Loc. Mdl

Org. Mdl

Process Mdl

Capab. Matrix

ReferenceEAMF

Project(s)

Reference BusinessArch(s)


Bus. Pattern Hierarchies

Bus. Arch.Model

Bus. Arch.Patterns/Reuse

Constraints


Use of Sparx Systems EA to Design the ABS-B2 Business Architecture


From Requirements Engineering to Business Architecture Engineering Using EAMF

Glossary

Stakeholder Requests

Business Objectives

Features and Events

Use Cases

Business Model

Business or Functional Requirements

Non Functional Requirements

Requirements Types

Software Development Lifecycle Phases

Requirements Engineering

Location

Organization

ProcessBusiness

Rules

Pattern/Product/Enterprise Solution Reqs

Business Rules Reqs Repository

Enterprise Solution Patterns Requirements

Enterprise Business Vocabulary Reqs

Business Strategy and Innovation Reqs

Enterprise Requirements

Enterprise Project Requirements

Req. Analysis

WorkflowRules


Strategy Definition

Concept Definition


Business Model

Requirements





Business Objective

Features and Events




Business Process

Requirements


Process Model

Requirements




Enterprise Glossary






Design

Relationships

Bus. Arch. Engineering

BUC Mdl

Domain ModelEntities

Bus. ProblemForce

Hierarchies

URN Mdl


Styles


Req Mdl Analysis


Bus. Arch.Design Artifacts

Analysis

Org. Mdl

Loc. Mdl

BUC Mdl

Loc. Mdl

Org. Mdl

Process Mdl

Capab. Matrix

ReferenceEAMF

Project(s)

Reference BusinessArch(s)


Bus. Pattern Hierarchies

Bus. Arch.Model

Bus. Arch.Patterns/Reuse

Constraints


Actor/Dependency and Goal/Plan Diagram (Late Requirements Discipline)

9/18/2006

13


Actor/Dependency Diagrams (Late Requirements Discipline)


Composite UCM Root Map for ESLM


Plug-In Map for HandleAllEvents in Root Map


Generic Plug-In Map for HandlePolicyServiceEventsand HandleInvoiceServiceEvents

9/18/2006

14


Generic Plug-In Map for ProcessAllRequests Stub in Root Map

eamf applied9/18/2006 2 architectural analysis using eamf 5 september 15 2006 from requirements to...

Documents