Design Mechanisms The path to successful projects

Post on 09-Feb-2016

41 views 0 download

description

Design Mechanisms The path to successful projects. Lars Fredholm MagicIT. Bio. Lars Fredholm, System Enginer IBM, RSV, LANI, MSC, MagicIT AB C, Clipper, VO, SQL-Windows, VB/MTS, Java Rose Experience since 1993 (Rose 2.x) Today: Rational OOAD/Rose Certified Instructor, MCP - PowerPoint PPT Presentation

Transcript of Design Mechanisms The path to successful projects

Design MechanismsThe path to successful projects

Lars FredholmMagicIT

Bio

Lars Fredholm, System Enginer IBM, RSV, LANI, MSC, MagicIT AB C, Clipper, VO, SQL-Windows, VB/MTS, Java Rose Experience since 1993 (Rose 2.x)Today: Rational OOAD/Rose Certified Instructor, MCP Consulting in Rational’s Tools

Architectural Mechanisms?

The Architect Mind

What does it mean technically?

Architectural Mechanisms? Technical functionality that is needed

WindowNavigatio

n

Persistency

Broker/Transaction

Security

Master/Detail

Communication

Language/Errors

Legacy System/

Import/Export

Devices

Reporting

Stateless/ State

GUIConcurrency/Distribution

Architectural MechanismsThree Categories

Architectural Mechanism Categories– Analysis Mechanisms (conceptual)– Design Mechanisms (concrete)– Implementation Mechanisms (actual)

Exampel – Persistence => Database => Sybase

Architectural Mechanisms have Characteristics

Persistency– Granularity: 1 to 10 Kbytes per row– Volume: up to 200000 rows– Access frequency

• Create: 500 per day• Read: 2,000 access per hour• Update: 1,000 per day• Delete: 50 per day

Communication– Synchronicity– Message Size– Protocol

Parts in RUPregarding Design Mechanisms

Inception / Early Elaboration– Requirements (functional and supplementary)– Build Technical Prototypes– SAD, Software Architecture Document

Elaboration– Model Design Mechanisms– Design Guidelines– Use Case Realization

Construction– Code Templates

Inception PhaseMilestone: Can we do this project?

Functional Requirements– Use Case survey, System scope, Priority

Non functional Requirements– Technical Prototypes (prove concept)

Candidate Architecture– Architecture Mechanisms

Project Plan– Cost and schedule

Functional RequirementsUse Case Model Survey

CompanyProject

Week

Employee

Gives Early Abstractions - Analysis Classes

Use-Case Model

Map to Analysis ClassesAnalysis Classes are early Classes

Mapping Mechanisms and Analysis Classes

Analysis Class Analysis Mechanism(s)

WeekProject

Employee

Company

ProjectController

Persistency, Security

Persistency, Legacy Interface

Persistency, Legacy Interface

Transaction

Persistency, Security

Non Functional Requirements Supplementary Specifications

GUIDevicesEnvironmentStorageCommunicationPerformanceDistribution

SupplementarySpecifications

Technical PrototypesTechnical prototypes proves the choice of Architecture and reduces Risks early

Validate Mechanism with Prototype If a Prototype doesnt exist, build it!

– GUI applet, graphical applet– Report applet, scanner applet– Database applet, transactions applet– Object broker applet– External system applet, import/export applet– Stress applets – Security applets

Candidate ArchitectureSoftware Architecture Document

Describes the Architecture by examples Shows Architecture significant examples of:

– Use Cases– Realizations– Class Diagrams– Process Diagrams– Component Diagrams– Deployment Diagrams– Data Model

SADSoftware Architecture Document

The Candidate Architecture

Elaboration Phase Milestone: Have we managed all questions regarding the Systems architecture?

Design Mechanisms– Design Patterns to Reuse

• Tested & proved technical Prototypes– Design Guidelines

• Rules to follow when designing the System

Use Case Realization– Use Case Scenarios with Iteration and Class

Diagrams

Design Mechanisms: Design Patterns

Parameterized Collaboration of components that solves a general design problem

Iteration Diagrams– Objects & Messages, Dynamic view

VOPC (View of Participating Classes)– Class Diagram, Static view

Technical Prototype– Code snippets

Design Pattern

Design Mechanisms

Inheritance– Use Structural behavior from Super Class

Delegation– Use build-in behavior from Subsystem

Role Classes (templates)– Reuse same behavior as modeled in Role Classes

Design Mechanisms,Design Pattern Styles

Design Mechanisms,Rose Design Model

Business Services

<<layer>>

Data Services<<layer>>

Design Mechanisms

User Services<<layer>> Use Case

Realizations

Design Model

Design Mechanisms,Package Overview

Design Mechanisms,Technical Use Case Diagram

Persistency

<<mechanism>>

Distribution<<mechanism>>

Security<<mechanism>>

Imaging<<mechanism>>

Transaction<<mechanism>>

Mechanism Client

GUI Navigation<<mechanism>>

Security Mechanismby Inheritance

Security Mechanism, Iteration Diagram

: Business

Object : cls

Session : cls

SecurityClient

1: ObjectPerm(String, clsSession)

2: ObjectPerm(String, clsSession)

3: ObjectPerm(String, PermissionType, RecordStatus)

4: Check Security Bit

Get Permission rights for Resource:3 * 5 binary bits1=Select, 2=New, 3=Update, 4=Softdelete, 5=Harddelete

Check if permission exist

Security Mechanism, VOPC, View of Participating Classes

clsSession

ObjectPerm()

Operation ObjectPerm() returns Permission rights for specified Resource:3 * 5 binary bits1=Select, 2=New, 3=Update, 4=Softdelete, 5=Harddelete

clsSecurity

ObjectPerm()SetResource()

(from Security)

Mechanism Client

Business Object

ObjectPerm()

<<role>>

Security Mechanism, Code Examples

'Check Permissions for resource

Public Function ChkRights(Session as clsSession, Resource as Object, Permission as Integer) As Boolean

On Error GoTo Catche

Dim strPerm as String

Try:

strPerm = Resource.ObjectPerm(Session)

Select Case Permission

Case 1 'Check VIEW permissions_ blnOk = Mid(strPerm,1,1)

Case 2 'Check NEW permissions _ blnOk = Mid(strPerm,2,1)

Case 3 'Check UPDATE permissions _ blnOk = Mid(strPerm,3,1)

Case 4 'Check DELETE permissions _ blnOk = Mid(strPerm,4,1)

Case Else _ blnOk=False

End Select

ChkRights=blnOk

Exit Function

Catche:

Err.Raise Err.number, Err.description, Err.source, Err.helpFile

End Function

Imaging Mechanismby Delegation

Security Mechanism, Iteration Diagram

Client

subsystem : ImageView

1: ImageNew( )

2: ImageScan( )

3: ImageSaveAs( )

4: PageInsertScan( )

5: ImageSave(VT_BOOL)

Imaging Mechanism, VOPC, View of Participating Classes

ImageViewMechanism Client

ImageSevices

(from User Services)

<<subsystem>>

Imaging Mechanism, Tech. Prototypes – Proved Concept

Transaction Mechanismby Role Classes

Transaction Mechanism, Iteration Diagram

role : Controller

: ObjectContextglobal :

AppServer

Client

Get Transaction Server Control ObjectContext

5: Error Exception

role : Business Object

Atomic SQL

6) Errors ROLLBACK

4) Successful COMMIT

2: GetObjectContext( )

ObjectContext 4: SetComplete( )6: SetAbort( )

3: ObjectSave()1: Transaction

Transaction Mechanism, VOPC, View of Participating Classes

ObjectContext

SetComplete()SetAbort()

(from Transaction Server)

AppServer

GetObjectContext()SafeRef()

(from Transaction Server)

Business Object(from Role Classes)

<<role>>

Controller

Transaction()

(from Role Classes)

<<role>>

Mechanism Client

Via Client ProxyGlobal

Business Object(from Role Classes)

<<role>>

Business Object

ObjectSave()

(from Role Classes)

<<role>>

Transaction Mechanism, Code snippets – Templates

'Operation on <<role>> Controller Class in Application Server

Public Function Transaction() As Boolean

On Error GoTo Catche

Dim objCtxObj As ObjectContext

Try:

'Get MTS context Object from Global AppServer

Set objCtxObj = GetObjectContext()

'Inform MTS of Transaction Completion

If Not objCtxObj Is Nothing Then objCtxObj.SetComplete

Exit Function

Catche:

'Inform MTS of Transaction Abortion

If Not objCtxObj Is Nothing Then objCtxObj.SetAbort

Err.Raise Err.number, Err.description, Err.source, Err.helpFile

End Function

Design GuidelinesHandbook for designers

The Communication Tool

Realization Package: Iteration Diagrams

– Dynamic ViewVOPC (View of Participating Classes)

– Class Diagram - Static view

Use Case Realization

Use-Case Model Design Model

Use Case Use-Case Realization

Realization,Package Overview

Realization,Use case Behavior distributed to classes

Åtgärd Skapa intäktsfel<<realization>>

Registrera skada<<realization>>

Hantera skada<<realization>>

Preparera intäktsfil

(from Användningsfal l)

<<realizes>>

Interndebiteringsunderlag

(from Användningsfal l)

<<realizes>>

Skapa kundfakturafil

(from Användningsfal l)

<<realizes>>

Use Case Realization, Realization with Design Mechanisms

Receptionist is a person working in the Reception with Customers.

Order is received from Customer by Receptionist. The Paper is Scanned and Customer information captured by the System.

Receive Order(from Användningsfal l)

Receptionist

(from Aktörer)

Use Case Realization, Realization with Design Mechanisms

Enter New Order is a part of the GUI Navigation Mechanism

Client

role : DetailPage

interface : iWindow

role : DetailPage

1: PrinterPrint( )3: ObjectNew( )6: ObjectView( )9: ObjectEdit( )

15: ObjectDelete( )18: RowNext( )

20: RowPrevious( )22: WindowClose( )

12: ObjectSave( )

5: ObjectNew( )8: ObjectView(Long)11: ObjectEdit(Long)

17: ObjectDelete(Long)14: ObjectSave( )

2: PrintForm4: ObjectNew(Boolean, iWindow)7: ObjectView(Boolean, iWindow)10: ObjectEdit(Boolean, iWindow)

16: ObjectDelete(iWindow)19: NextRow( )

21: PreviousRow( )23: Unload

13: ObjectSave( )

Use Case Realization, Realization with Design Mechanisms

GUI Navigation MechanismRole Class PageDetail cloned to frmOrder

: Receptionist

: frmOrder

1: ObjectNew( )MechanismGUI Navigation

Use Case Realization, Realization with Design Mechanisms

Imaging MechanismNo need to model deeper into SubsystemAlready fully modeled in Mechanisms

: Receptionist

: frmOrder : ImageView

1: ObjectNew( )MechanismGUI Navigation

2: Scan3: ImageNew( )Mechanism

Imaging

Use Case Realization, Realization with Design Mechanisms

Persistency Mechanism - clone clsOrder

: Receptionist

: frmOrder : ImageView : clsOrder

1: ObjectNew( )MechanismGUI Navigation

2: Scan3: ImageNew( )Mechanism

Imaging4: Enter Data

5: ObjectSave( )MechanismPersistency

6: ObjectNew(Recordset, clsSession, Long, String)

7: ObjectSave(Recordset, clsSession, Recordset, Boolean)

Use Case Realization, Realization with Design Mechanisms

All Mechanisms

: Receptionist

frmOrder : iWindow

: ImageView : clsOrder : OrderController

1: ObjectNew( )MechanismGUI Navigation

2: Scan3: ImageNew( )Mechanism

Imaging4: (Enter Data)

5: ObjectSave( )

MechanismPersistency / Distribution

6: RetreiveOrder( )

8: ObjectNew(Recordset, clsSession, Long, String)

MechanismTransaction

7: ObjectPerm(String, clsSession)MechanismSecurity

9: WindowClose( )

Use Case Realization, Long version

Without Mechanisms – a long long version : Receptionist

frmOrder : iWindow

: ImageView : clsOrder : clsOrderList : iMenu : frmOrder : OrderController

1: ObjectNew( )

5: Scan

9: (Enter Data)

10: ObjectSave( )

19: WindowClose( )

6: ImageNew( )

15: ObjectNew(Recordset, clsSession, Long, String)

14: ObjectPerm(String, clsSession)

11: ObjectSave( )

13: RetreiveOrder( )

17: ObjectSave(Recordset, clsSession, Recordset, Boolean)

18: Validate(Boolean, clsSession, Recordset, String, Variant)

16: Fetch(Recordset, clsSession, Long, String)

2: Init(clsApplication, iWindow)

12: Data( )

3: ObjectNew( )

7: ImageScan( )

8: ImageSaveAs( )

4: MenuDetailNew( )

20: MenuReset( )

Construction PhaseMilestone: Are we ready to install?

Is it Good Quality code?Are executables Stable and Tested? Is System documented and mantainable?Will User receive high usability? Is it inside timeframe (TTM)?

Code TemplatesCode snippets with variation points

Design Mechanisms gives reusable beaviour

Resusable beaviour are code segments with variation points (Roles)

Copy boring repeating codeFocus on essential programming tasksReusable code already testedCode Templates could be written

AutomationEnhanced by Design Mechanisms

Code Automation:Rose Code Generation (Stubs)Copy & Paste programmingCode WizardsTemplate ToolsRose Reversing Code (Round Trip)

SummaryUsing Design mechanisms

Inception– Anaysis Mechanisms identifies risks early

Elaboration– Design Mechanisms reduces risks early– Design Mechanisms accelerates modeling

Construction– Templates code reduces risks early– Templates code accelerates coding– Templates code increases quality of the code

Design MechanismsThe Vehicle to successful projects

www.magicIT.com

Lars Fredholm

Thank You!Thank You!