WOC2006 Presentation: Design Workshop

Ingeniørhøjskolen i Århus Slide 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?

Ingeniørhøjskolen i Århus Slide 3 af 19 Basic OO Design – Use Case Driven Use Case N Actor 1 Use Case spec. “Models” the domain e.g. an Orienteer or Radiopost. System/Actor Interaction Use Case impl. Links Model & Boundry «control» «boundary» «entity» Domain Model for Use Case N Logic Domain Model from the Analysis OOA 1)We are here now! 2)This is were we are going!

Ingeniørhøjskolen i Århus Slide 4 af 19 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 2 Actor 1 D1 class «entity» D2 class «entity» D3 class «entity» These might be generated by tool / framework

Ingeniørhøjskolen i Århus Slide 5 af 19 “4+1 View” model for SW arkitektur Logical View Implementation View (development) Process View Komponenter, Lag Klasser, Packages Interfaces 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

Ingeniørhøjskolen i Århus Slide 6 af 19 Bruce Eckel’s ROPES Model Architecture design Scope: nodes, packages (sub systems), components (e.g. a driver DLL), tasks Mechanistic design Scope: Group of collaboratingclasses Class Node Package Component Active object Detailed design Scope: Class Class name Attributes Operations Bd. s193

Ingeniørhøjskolen i Århus Slide 7 af 19 UI Processor «processor» X Position Knob Y Position Knob RS-232 LCD Display «display» X-axis Controller «processor» Y-axis Controller «processor» Ethernet 1Mbit TCP/IP X-axis Stepper Motor «actuator» X-axis Position Sensor «sensor» RS-485 Y-axis Stepper Motor «actuator» Y-axis Position Sensor «sensor» RS-485 BD.s204

Ingeniørhøjskolen i Århus Slide 8 af 19 Details UI Processor «processor» Display Subsystem Input Subsystem Communications Component iSend iReceive Update Display Monitor Encoders Message Management Chip Driver BD.s204

Ingeniørhøjskolen i Århus Slide 9 af 19 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

Ingeniørhøjskolen i Århus Slide 10 af 19 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.

Ingeniørhøjskolen i Århus Slide 11 af 19 Non-UML tier representation WOC Adm InternetPush Model Control 1Control 2 RDBMS See more on:

Ingeniørhøjskolen i Århus Slide 12 af 19 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

Ingeniørhøjskolen i Århus Slide 13 af 19 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

Ingeniørhøjskolen i Århus Slide 14 af 19 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

Ingeniørhøjskolen i Århus Slide 15 af 19 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?

Ingeniørhøjskolen i Århus Slide 16 af 19 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?

Ingeniørhøjskolen i Århus Slide 17 af 19 JSP model 2 (MVC) –Based on the MVC pattern –Model chosen for many larger applications –Basically the one used in the Struts framework – 12-ssj-jspmvc.html and 12-ssj-jspmvc.htmlhttp://struts.apache.org/ Struts? Hibernate?

Ingeniørhøjskolen i Århus Slide 18 af 19 Struts & Hibernate Links to Struts: – – Links to Hibernate: – – Turbine / Velocity / Hibernate: – – – howto.htmlhttp://jakarta.apache.org/turbine/turbine-2.3/howto/hibernate- howto.html

Ingeniørhøjskolen i Århus Slide 19 af 19 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?