woc2006 presentation: design workshop. ingeniørhøjskolen i Århus slide 2 af 19 agenda formål:...

WOC2006

Presentation:

Design Workshop

Ingeniørhøjskolen i ÅrhusSlide 2 af 19

Agenda

• Formål: Skabe en fælles forståelse• Vi fokuserer på domænemodellen og deployment• Disse er de vigtigste for samarbejde mellem systemer

(grænseflader)• Udfordringer er blandt andet:

– Hvor skal grænsefladerne trækkes mellem de enkelte projekter– Taler vi samme server, eller har vi behov for en distribueret

løsning?– Hvad vil I have med i jeres rapport (meta-metode)

• Sekvensdiagrammer vil som oftest ikke være relevante for grænsefladeklasserne, hvis systemet er designet til en høj grad af afkobling

• Kan man altid forvente en høj grad af afkobling? Også i dette projekt?


Basic OO Design – Use Case Driven

Use Case N

Actor 1

Use Casespec.

“Models” the domaine.g. an Orienteer or

Radiopost.

System/ActorInteraction

Use Case impl.Links Model & Boundry

«control»

«boundary»

«entity»

Domain Model for Use Case N

Logic DomainModel from the Analysis

OOA

1)We are here now!

2)This is were we are going!


From Use Case to Domain Model

Use Case N class

«control»Actor 1

A1 class

«boundary»

A2 class

«boundary»

Actor 2

Use Case N

Actor 2Actor 1

D1 class«entity

» D2 class«entity

» D3 class«entity

»

These might be generated by tool / frameworkThese might be generated by tool / framework


“4+1 View” model for SW arkitektur

Logical ViewImplementation View (development)

Process View

Komponenter,Lag

Klasser, PackagesInterfaces

Processer, Threads, Tasks

Deployment View(Physical)

Nodes

Use Case View

Use cases

Ref.: Philippe Kruchten, ”The 4+1 View of Architecture,”IEEE Software, 12(6) Nov. 1995


Bruce Eckel’s ROPES ModelArchitecture design

Scope: nodes, packages (sub systems), components (e.g. a driver DLL), tasks

Mechanistic design

Scope: Group of collaboratingclasses Class

Class

Class

Class

Node

Package

ComponentActive object

Detailed designScope: Class

Class name

Attributes

Operations

Bd. s193


UI Processor

«processor» X PositionKnob

Y PositionKnob

RS-232

RS-232

LCDDisplay

«display»

X-axisController

«processor»Y-axis

Controller

«processor»

Ethernet 1Mbit TCP/IP

X-axisStepperMotor

«actuator»X-axis

PositionSensor

«sensor»

RS-485 RS-485

Y-axisStepperMotor

«actuator»Y-axis

PositionSensor

«sensor»

RS-485 RS-485

BD.s204


Details

UI Processor «processor»

Display Subsystem

Input Subsystem

Communications Component iSend

iReceive

UpdateDisplay

MonitorEncoders

MessageManagement

ChipDriver

BD.s204


Use Sub-systems for Structuring

• Subsystems are used for structuring your code

• Group relevant classes in subsystems

• Consider whether each group has a– separate system /– subsystem

• Often used in layered design activities


Design by Layering

• Client Presentation tier– Provides a user interface to the end-users. – Thin/Rich. MVC.

• Server Side Presentation tier– Building a response to the Client Presentation tier.

• Server Side Business Logic tier– Use Case implementation. Control classes. Business logic.

• Server Side Domain Model tier– Domain Model. Entity classes.

• Enterprise Integration tier– Legacy system. Web services.

• Persistence tier / Resource layer / Data Access Layer– Relational Database. File-system. Legacy.


Non-UML tier representation

WOC Adm Internet Push

Model

Control 1 Control 2

RDBMS

See more on: http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html


Using Design Patterns

• Design patterns address specific programming tasks, rather than solving business problems.

• Design patterns provide guidelines, not actual implementation.

• Design patterns are reusable. • Design patterns have a proven track record. • Design patterns help you communicate your

design ideas to other designers


Design Patterns Examples

• ”Classic Design Patterns”:– Singleton– Observer– Iterator– Facade– Proxy (you have already seen this)– Factory– Many others

• All may be used, but some must be adjusted• Remember: patterns are only for inspiration

– NOT dictate


Façade Pattern (GoF)

Used for encapsulation and decoupling – usually one pr sub-systemUsed for encapsulation and decoupling – usually one pr sub-system

Especially important with the Event Database Group – full access locks down code Especially important with the Event Database Group – full access locks down code


Building the architecture

• How do we get from the logic domain model to the finished product?– We need a GUI layer – HTML?– Gets generated by JSP / Servlets?– We need a control layer – Servlets or

Java beans?– We need a model layer – does this

include the DAL? – is it generated by the framework?

– Database layer – this we got

Which framework?Which framework?

Which framework?Which framework?


JSP Model 1

– Model chosen in many ”homemade” frameworks– Does your framework use this?– Is this ”good enough” for your project– Does all projects have to use the same model?


JSP model 2 (MVC)

– Based on the MVC pattern– Model chosen for many larger applications– Basically the one used in the Struts framework– http://www.javaworld.com/javaworld/jw-12-1999/jw-

12-ssj-jspmvc.html and http://struts.apache.org/

Struts?

Hibernate?


Struts & Hibernate

• Links to Struts:– http://struts.apache.org/ – http://www.itjungle.com/fhg/fhg042104-story01.html

• Links to Hibernate:– http://hibernate.org – http://www.itjungle.com/fhg/fhg030304-story01.html

• Turbine / Velocity / Hibernate:– http://jakarta.apache.org/turbine/ – http://jakarta.apache.org/turbine/turbine-concepts.html – http://jakarta.apache.org/turbine/turbine-2.3/howto/hibernate-

howto.html


What’s next?

• Can we easily transform the logic domain model to a technical model?

• Can we agree on at least some of the layers, e.g. the model?

• Were do we place the “cut” between the systems?

Cut here?

Last option cut

Struts? Fat Apps?

woc2006 presentation: design workshop. ingeniørhøjskolen i Århus slide 2 af 19 agenda formål:...

Documents