1 / 77

Conceptual Architecture View

Conceptual Architecture View. ZHAO Jianhua Dept. of Computer Sci&Tech Nanjing University. Conceptual architecture view. closest to the application domain, least constrained by the software and hardware platforms.

elsu
Download Presentation

Conceptual Architecture View

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Conceptual Architecture View ZHAO Jianhua Dept. of Computer Sci&Tech Nanjing University

  2. Conceptual architecture view • closest to the application domain, least constrained by the software and hardware platforms. • Model the product as a collection of decomposable, interconnected conceptual components and connectors. • A critical goal is to keep the control aspects of the components simple, and to isolate control in the connectors

  3. Conceptual architecture view(2) • We need other architecture views to show how the conceptual architecture model is mapped to today’s programming languages, OS, communication mechanisms, and so forth. • When designing the conceptual view: • Global properties such as performance and dependability should also be treated: performance. • Some other properties should still be considered in other views: portability.

  4. Domain-specific or reference architecture • Domain specific or reference architecture could be the starting point for your conceptual view. • Whether it can be starting point depends on whether the architecture uses a computational model consistent with the conceptual view.

  5. Reason about conceptual view • We can reason whether the system fulfill the requirement and global properties based on the conceptual view. • If you are using use-case and/or scenarios to capture the system’s desired behavior, the conceptual view should be able to handle satisfactorily all the use-cases and scenarios.

  6. Design activities • Three phases to the conceptual view design: • Global analysis • Central design tasks • conceptual components • conceptual connectors • global evaluation • conceptual configuration • final design task • Resource budgets: assign resources to the components and connectors in the configuration.

  7. Diagram of Design Tasks • Figure 4.1, PAGE 63 central design tasks Final Design Tasks com-ponents con-nectors GA resource budgeting global evaluation conceptual configuration Module view Execution View central design tasks central design tasks

  8. Global analysis for Conceptual View Design • First: Review the product requirements, use-cases, and the system requirements.Make sure you understand: • the interface to the environment • the users • and other systems that interact with this system. • functional requirements • system qualities and global properties.

  9. Global analysis for Conceptual View Design(2) • Next • analyze the product, technological, and organizational factors, producing factor tables. • identify issues, develop strategies

  10. Global analysis for Conceptual View Design • Focus on the factors most relevant to the conceptual view: • All the product factors • Technological factors: domain-specific hardware and architecture tech, domain-specific standards • Organizational factors: management, development schedule, development budget • You should capture most of the important factors which affect this view.

  11. Central Design Tasks • Using the strategies to guide the design • Define the components and the connectors. • The majority of components come from the requirement and the domain.

  12. Central Design Tasks(Activities) • There are four activities in the central design tasks. The order in which you do these things are not fixed. • The four activities during central design: • Define component and connector types • Define how component and connector types interconnect.

  13. Central Design Tasks(Activities) • Map the system functionality to components and connectors. • Functional behavior in components • Control aspects in connectors. • Define the instances of the component and connector types that exist in the product, and how they are interconnected.

  14. Starting from domain-specific or reference architecture • Some of the component and connector types are provided. • There are some constraints on how they interact. • Provide how to map the system functionality to components and connectors. • A product-line architecture provides a similar starting point.

  15. Evaluate the results • The strategies from global analysis constraint or guide many of your decisions. • Continually evaluate the result to make sure you are following the strategies. • Also review the factor tables to make sure you account for the relevant factors.

  16. Conceptual Components • You must define both the components types and instances of those type. • The functional behavior of the system is in components. • The components can still be decomposed into components and connectors. • The behavior of the components should also be described: Statechart Diagram, natural language description, ….

  17. Conceptual Components(2) • Contains ports, which are the interaction points. Port is not an interface • interface defines only what the system provides, no what it uses. • ports have implementation but interface doesn't. • Each port has an associated protocol.

  18. * * CComponent CConnector 0..1 0..1 0..1 * CPort * Obeys> Protocol UML diagram of conceptual component 1

  19. Conceptual Connectors • Define the connector types and the instances of the types. • The control of the system is concentrated in the connectors. • Connectors can be decomposed into components and connectors.

  20. Conceptual Connectors • Connectors contain roles as the point of interaction with other architecture elements. • The roles obey an associated protocol. • You may need to describe the behavior of connectors. • you must focus on the control aspects.

  21. * * CComponent CConnector 0..1 0..1 0..1 * CRole Obeys> * 1 Protocol UML Diagram of connectors

  22. Conceptual Configuration • Define the relations among the components and connectors. • Two type of configurations • containing component and connector types: constrains how the instances of component and connector types can be interconnected. • containing component and connector instances: defines which instances exists in the product and how they interconnect.

  23. Conceptual Configuration • Components and connectors are interconnected through their ports and roles. • Connection are possible only when • the associated protocols are compatible and • the elements are nested within the same component or connector. • The binding relation is used when a component or connector is decomposed to bind an inner port to a port of the enclosing component,

  24. * * * * CPort CRole cconnection * * cbinding cbinding UML Diagram of configuration {cconnection can connect cport and crole only when the respective ccomponent and cconnector are enclosed directly by the same element} {connected cport and crole should have compatible protocols} {cbinding can connect cport(crole) only to a cport(crole) of the enclosing ccomponent(cconnector)

  25. Global Evaluation • During the central design tasks you must also periodically evaluate the interactions among your decisions.

  26. Final Design Task: Resource Budgeting • To budget resources for the component and connector instances identified during the central design tasks. • An opportunity to evaluate properties earlier. • Identify critical application-level resources and assign budgets. • A major redesign of the system maybe needed.

  27. Strategies developed for IS2000 • Issue: Aggressive Schedule • Make it easy to add or remove features • Issue: Changes in General-Purpose and Domain–Specific Hardware • Encapsulate domain-specific hardware

  28. strategies developed for IS2000(2) • Issue: Easy Addition and Removal of Features • Separate components and modules along dimensions of concern. • Encapsulate features into separate components • Decouple the user interaction model.

  29. More specific issues • Easy addition and removal of acquisition procedures and processing algorithms. • Real-Time Acquisition Performance

  30. Issue card for Easy Addition and Removal … • Solution: • Define domain-specific abstractions to facilitate the task of implementing acquisition and processing applications. • Strategy: • Use a flexible pipeline model for image processing • Introduce components for acquisition and image processing • Encapsulate domain-specific image data.

  31. Issue card forReal-Time Acquisition Performance • Solution: • Partition the system into separate components for algorithms, communication, and control to provide the flexibility to implement several different strategies. • Strategy: • Separate time-critical components form nontime-critical components.

  32. The start conceptual view The strategy: • Introduce components for acquisition and image processing

  33. Initial high-level configuration of IS2000 • Figure 4.5, PAGE 72 probeCommands :Acquisition userAcqControl sender imagingControl receiver acqControl :Imaging probeData userAcqDisplay imagesOut dest :Exporting userImageExport source imagesIn

  34. Decomposing the system • Encapsulate domain-specific hardware. • Create a component for communicating with the probe in both the Acquisition and the Imaging components: ProbeControl, DataCollection • They will be in same layer in module view.

  35. Decomposing the system • Decouple the user interaction model • introduce separate components within Acquisition, Imaging, and Exporting to handle the interaction: Acquire, Monitor, and Export.

  36. Decomposing the system(2) • Separate components and modules along dimensions of concern • the component AcquisitionManagement to set the policies for processing and organizing images.

  37. Decomposing the system(2) • Separate time-critical from nontime-critical components • Split the processing of images into ImageProcessing and PostProcessing. • ImageProcessing for time-cirtical initial procesing of the raw data. • Encapsulate domain-specific image data • Decompose Exporting component into the Image Collection, Export, and Comm.

  38. Refined high-level configuration of IS2000 • Figure 4.6 PAGE 73 • It’s not the final configuration. • Not all the ports have been named. • connectors are only roughly defined.

  39. Refining the ImageProcessing Component • responsible for framing raw data into images. • time critical part of IS2000. • Controlled according to the acquisition procedure through the acqControl port.

  40. Refining the ImageProcessing Component • Applied strategies: • Use a flexible pipeline model for image processing • There is one Packetizer, which bundles the incoming data into packets. • All the pipelines receive the same data from the packetizer and filter out what they don’t need.

  41. The diagram of ImageProcessing decomposition • Figure 4.7, PAGE 75 rawData Input acqControl packetOut Packetizer dest PacketPipe source acqControl ImagePipeline * franedOutput

  42. Defining Protocols and Behavior • A protocol is defined as a set of incoming message types, outgoing message types and the valid message exchange sequences. • Using sequence diagram to define the interleaving of the messages. • Using a statechart diagram to define the behavior of a component.

  43. Protocols for Packetizer and PacketPipe • Figure 4.8, PAGE 76 <<ccomponent>> Packetizer <<cconnector>> PacketPipe <<cport>> rawDataInput <<cport>> packetOut <<crole>> source <<crole>> dest obeys conjugate obeys conjugate obeys obeys <<protocol>> RawData <<protocol>> DataPacket <<protocol>> Request-DataPacket

  44. Packetizer <<protocol>> RawData dataReady incoming dataReady rawData(rd) requestData outgoing requestData rawData(rd) RawData Protocol • Figure 4.9, PAGE 76

  45. <<protocol>> DataPacket incoming outgoing packet(pd) DataPacket protocol • Figure 4.10, PAGE 77 Packetizer packet(pd)

  46. About UML Statechart • Composed of a finite set of state and the transitions among the state. • Each state represents a state of the system.

  47. About UML Statechart • Each transition between states represents a possibility of going into the target state from the source. • Each transition has three parts of the form Event[Guard]/Action. • Event: incoming message • Guard: logical condition • Action: sending an outgoing message.

  48. Packetizer behavior • Figure 4.11 PAGE 78 Init packet Idle [PacketFull]/ packet(pd) dataReady/ requestData [packetNotFull add data to packet wait for data rawData(rd)

  49. <<protocol>> RequestDataPacket incoming packet(pd) outgoing subscribe(c) desubscribe(c) requestPacket(c) RequestDataPacket protocol • Figure 4.12, PAGE 78 ImagePipeline subscribe(c) *requestPacket(c) *c.packet(pd) desubscribe(c)

  50. PacketPipe connector behavior • Figure 4.13, PAGE 79 subscribe(c)/ add client desubscribe(c)/ remove client [packet read by all] update packet Waiting packet(pd)/ assign to queue [no client ready] assign packet to ready clients requestPacket(c) [packet not read]/ c.packet(pd) requestPacket(c) [packet read]/ mark client ready [ready client]/ c.packet(pd)

More Related