WOC2006

1
WOC2006

• Presentation
• Design Workshop

2
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?

3
Basic OO Design Use Case Driven
1)We are here now!
Use Case N
Use Case spec.
OOA
Logic Domain Model from the Analysis
2)This is were we are going!
4
From Use Case to Domain Model
These might be generated by tool / framework
5
41 View model for SW arkitektur
Implementation View (development)
Logical View
Komponenter, Lag
Klasser, Packages Interfaces
Use cases
Use Case View
Deployment View (Physical)
Process View
Processer, Threads, Tasks
Nodes
Ref. Philippe Kruchten, The 41 View of
Architecture,IEEE Software, 12(6) Nov. 1995
6
Bruce Eckels ROPES Model
Architecture designScope nodes, packages (sub
systems), components (e.g. a driver DLL), tasks
Component
Active object
Bd. s193
7
processor
X Position Knob
RS-232
display
UI Processor
LCD Display
RS-232
Y Position Knob
Ethernet 1Mbit TCP/IP
processor
processor
Y-axis Controller
X-axis Controller
RS-485
RS-485
RS-485
RS-485
sensor
actuator
sensor
actuator
Y-axis Position Sensor
Y-axis Stepper Motor
X-axis Position Sensor
X-axis Stepper Motor
BD.s204
8
Details
processor
UI Processor
Display Subsystem
Input Subsystem
Update Display
Monitor Encoders
Communications Component
iSend
Message Management
Chip Driver
iReceive
BD.s204
9
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

10
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.

11
Non-UML tier representation
Internet
Push
Control 1
Control 2
Model
RDBMS
See more on http//www.javaworld.com/javaworld/jw
-07-2004/jw-0719-jsf.html
12
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

13
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

14
Façade Pattern (GoF)
Used for encapsulation and decoupling usually
one pr sub-system
Especially important with the Event Database
Group full access locks down code
15
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?
16
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?

17
JSP model 2 (MVC)
Struts?
Hibernate?

• 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-1
  2-ssj-jspmvc.html and http//struts.apache.org/

18
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/howt
  o/hibernate-howto.html

19
Whats next?
Struts?
Fat Apps?

• 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