Conceptual Architecture View

Conceptual Architecture ViewZHAO JianhuaDept. of Computer Sci&TechNanjing University

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

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.

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.

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.

Design activitiesThree 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.

Diagram of Design TasksFigure 4.1, PAGE 63

GAcom-ponents

con-nectors

global evaluation

conceptual configuration

central design tasksFinal Design Tasks

resource budgeting

Execution View

central design tasks

Module view

central design tasks

Global analysis for Conceptual View DesignFirst: 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.

Global analysis for Conceptual View Design(2)

Next analyze the product, technological,

and organizational factors, producing factor tables.

identify issues, develop strategies

Global analysis for Conceptual View DesignFocus 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 budgetYou should capture most of the important factors which affect this view.

Central Design TasksUsing the strategies to guide the designDefine the components and the connectors.The majority of components come from the requirement and the domain.

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.

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.

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.

Evaluate the resultsThe 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.

Conceptual ComponentsYou 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, ….

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.

UML diagram of conceptual component

1

CComponent

CPort

CConnector

Protocol

*

* *

0..1 0..1 0..1

Obeys>

*

Conceptual ConnectorsDefine 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.

Conceptual ConnectorsConnectors 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.

UML Diagram of connectors

CComponent

Protocol

CRole

CConnector

0..10..1 0..1

*

*

*

Obeys

>

*

1

Conceptual ConfigurationDefine 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.

Conceptual ConfigurationComponents 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,

UML Diagram of configuration

CPort CRole* **

**

*

cconnection

cbinding cbinding

{cbinding can connect cport(crole) only to a cport(crole) of the enclosing ccomponent(cconnector)

{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}

Global EvaluationDuring the central design tasks you must also periodically evaluate the interactions among your decisions.

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.

Strategies developed for IS2000

Issue: Aggressive Schedule Make it easy to add or remove

featuresIssue: Changes in General-Purpose and Domain–Specific Hardware Encapsulate domain-specific hardware

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.

More specific issuesEasy addition and removal of acquisition procedures and processing algorithms.Real-Time Acquisition Performance

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.

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.

The start conceptual viewThe strategy:

Introduce components for acquisition and image processing

Initial high-level configuration of IS2000

Figure 4.5, PAGE 72

:Acquisition

:Imaging

:Exporting

probeCommands

probeData

userAcqDisplay

userAcqControl

userImageExport

sender

receiver

imagingControl

acqControl

imagesOut

source

dest

imagesIn

Decomposing the systemEncapsulate 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.

Decomposing the systemDecouple the user interaction model introduce separate components

within Acquisition, Imaging, and Exporting to handle the interaction: Acquire, Monitor, and Export.

Decomposing the system(2)

Separate components and modules along dimensions of concern the component

AcquisitionManagement to set the policies for processing and organizing images.

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.

Refined high-level configuration of IS2000

Figure 4.6 PAGE 73It’s not the final configuration. Not all the ports have been named. connectors are only roughly defined.

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.

Refining the ImageProcessing Component

Applied strategies: Use a flexible pipeline model for image

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

The diagram of ImageProcessing decomposition

Figure 4.7, PAGE 75

Packetizer PacketPipe

ImagePipeline*

acqControl

acqControl

rawData Input packetOu

t

source

dest

franedOutput

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.

Protocols for Packetizer and PacketPipeFigure 4.8, PAGE 76

<<ccomponent>>Packetizer

<<cport>>rawDataInput

<<cport>>packetOut

<<protocol>>RawData

obeys <<protocol>

>DataPacket

obeys

<<crole>>sourceobeys

conjugate

<<cconnector>>PacketPipe

<<crole>>dest

<<protocol>>Request-DataPacket

obeys conjugate

RawData ProtocolFigure 4.9, PAGE 76

Packetizer dataRead

y

requestData

rawData(rd)

<<protocol>>RawData incomingdataReadyrawData(rd) outgoingrequestData

DataPacket protocolFigure 4.10, PAGE 77

<<protocol>>DataPacket incoming outgoingpacket(pd)

Packetizer

packet(pd)

About UML StatechartComposed of a finite set of state and the transitions among the state.Each state represents a state of the system.

About UML StatechartEach 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.

Packetizer behaviorFigure 4.11 PAGE 78

Init packet

Idle

wait for data

add data to packet rawData(r

d)

dataReady/requestData

[packetNotFull

[PacketFull]/packet(pd)

RequestDataPacket protocol

Figure 4.12, PAGE 78<<protocol>>RequestDataPacket incomingpacket(pd) outgoingsubscribe(c)desubscribe(c)requestPacket(c)

ImagePipelinesubscribe(c)

*requestPacket(c)*c.packet(pd)desubscribe(c)

PacketPipe connector behavior

Figure 4.13, PAGE 79

Waiting

subscribe(c)/add client

packet(pd)/assign to queue

requestPacket(c)[packet not read]/c.packet(pd)

requestPacket(c)[packet read]/mark client ready

desubscribe(c)/remove client

assign packet to ready clients

[no client ready]

[packet read by all] update packet

[ready client]/c.packet(pd)

Using these diagramsWe can use these diagrams to Reason about the overall behaviors of

the system. Check whether the protocols and the

behaviors are consistent.

The ImagePipeline ComponentStrategies applied:

Use a flexible pipeline model for image processing.

Decomposition of ImagePipeline

ImagePipeline is decomposed into a number of stages and a pipeline manager.Framer: the first stage. One port is bound to packetIn Another is bound to framedOutput or

another ImgePipe

Decomposition of ImagePipeline(2)

The stages process a continuous stream of data, and pass it on to the next stage.The connector ImagePipes transmit a stream of data from one stage to another.PipelineMgr handles initialization and control messages from outside the system.

Decomposition of ImagePipeline(3)

The PipelineMgr can start, stop, pause, and shutdown the Imagers. This control from PipelineMgr is in

high level and seen by users.The framer checks for any message from PipelineMgr. It request packets from Packetizer and processes them.

The decomposed ImagePipeline

Figure 4.14, PAGE 80(part)

Framer ImagePipe1..*

Imager

PipelineMgr

The behavior of ImageProcessing

Figure 4.15, Page 82This figure show the collaboration of the components.

:Framer

packet(pd)

startImage

endOfImage

startUp

image(id)

Recovery and DiagnosticsConsider additional global properties: failure detection, reporting, recovery.Return to global analysis to add product factors, then develop additional strategies for handling them.Table 4.2, Page 84.

Recovery and DiagnosticsProduct factor: the image data must be recoverable in the event of a failure.Product factor: error classification, error logging, and support for using error logs in diagnosis.Recovery and Diagnostics may have a major impact on the architecture design.Two more issues are identified: Impl. of Recovery; Impl. of Diagnostics.

Issue card for Impl. of Recovery

Recovery is the responsibility of many components. Support for recovery is uniformly implemented by all relevant components.Influencing Factors: P5.4Solution Apply the principle of separation of concerns to

introduce a separate recovery mode of operation for each component. Ensure the data to be recovered is accessible to all components.

Issue card for Impl. of Recovery(2)

Strategy: Introduce a recovery mode of operation.Strategy: Make all data at the point of recovery persistent and accessible.

Issue card for Impl. of Diagnostics

Error logging will be used to support diagnostics. Responsibility for diagnostics is shared by all components. We need to ensure that support for diagnostics is uniformly implemented by all components.Influencing Factors: P5.1, P5.2, P5.3Solution: The design includes: the log, the types of

errors, the kind of information. Components need to log information, and the users needs to be able to read.

Issue card for Impl. of Diagnostics(2)

Strategy: Define an error-handling policy.Strategy: Reduce effort for error handling.Strategy: Encapsulate diagnostics componentsStrategy: Use standard logging services.

About Impl. of RecoveryThe strategy Make all data at the point of recovery persistent and accessible, influences where we draw the boundaries among the components.Three potential places of recovery: at the point where data is coming into

ImageProcessing between ImageProcessing and PostProcessing. Leaving PostProcessing.

About Impl. of Recovery(2)If one of the three points is feasible, then no structural changes is necessary.If not, we may need to divide one component to two, or shift the boundary.Any potential changes should also be evaluated w.r.t. related strategies.

About Impl. of Recovery(3)The point between the ImageProcessing and PostProcessing is feasible.The connector between ImageProcessing and PostProcessing must have the property: all data should be persistent. So a new connector type is introduced: PersistentDataPipe.We need to add components that encapsulate the functionality for recovery mode. and add new recovery port to existing components.

About the Impl. of diagnostics

Two new components are introduced: Logger: responsible for receiving and

storing event messages. LogReader: allows user to review the

logs.Existing components need a new logging port.

Final Design Task: Resource Budgeting IS2000

The resources we consider are those that are limited or are to be shared.If we can not come up with a balanced budget, we must return to the central design tasks with additional information about resource constraints.

Final Design Task: Resource Budgeting IS2000

Memory budget: based on the speed of data production and consuming. FIFO queues for the pipes between the

pipeline stages. Budget for PersistentDataPipe, the connector

between ImageProcessing, …Time budget: based on the sum of data to be operated during a time unit. computation time budgets for the components

responsible for time-critical activities.

Design Summary for IS2000

Identify componentsIntroduce connectors and communication protocols.Global properties make us to change the architecture previously designed.The design decision and their rationale is in Table 4.3, page 88-90

Summary of elements in Conceptual Architecture View

Ccomponent <Active class>Cport <Class>Cconnector <Active class>Crole <Class>Protocol <Class>


Relations composition cbinding cconnection obeys obeys conjugate


Artifact Conceptual configuration: UML Class

Diagram Port or role protocol: ROOM protocol

declaration Component or connector behavior :

Natural language description or UML Statechart Diagram

Interactions among components : UML Sequence Diagram

Meta-model of the conceptual architecture view

CComponent

Conceptual Configuration

Protocol

CPort CRole

CConnector

1 1

1 1

* *** * *

*

*

** *

*

*

**

0..1 0..1 0..1 0..1 0..1 0..1

TraceabilityDescribing the relationships of the conceptual architecture view to requirements, external factors, and other views provides traceability.

TraceabilityTrace two items:

Critical requirements Product features and requirements can be

traced to the conceptual elements.Organizational and technological factors. Makes it easier to understand the

implications of change during the design process and in the future.

Uses for the conceptual architecture viewYou may use the conceptual view for

Use-cases and scenariosPerformance estimationSafety and reliability analysisTarget independent testingUnderstanding the static and dynamic configurability of the system.Effort estimation.

Documents

Conceptual Architecture View