4.4 Execute (develop the logical design)

 < Day Day Up > 

4.4 Execute (develop the logical design)

Once we have a good handle on the solution requirements we can begin to develop the logical design.

Step 2A - Derive initial AOD

As before, we start by defining the functional subsystems that we will use to seed the initial Architecture Overview Diagram (subsystem). It may be the case that this initial AOD is derived directly from the matched large reusable asset. When such a work product isn't available as part of the matched large reusable asset, you can derive the functional subsystems by grouping the use cases based on related business patterns and common data or processing.

Table 4-3: Functional blocks for IFB AOD

Functional Subsystems

Associated Use Cases

User Management

  • User Management (SS)

  • Authenticate and Authorize User (AccI)


  • Apply for Job (SS)

  • Job Solicitation (C)

Labor Scheduling

  • Review and Guide Schedule (SS)

  • Generate Schedule (SS)

Task Management

  • Manage Tasks (SS)

  • Review and Perform Tasks (SS)

Corporate Collaboration

Corporate Collaboration (C)

Access HR

  • Update Personnel Record (SS)

  • Manage Compensation and Benefits (SS)

Customer Service

Access Customer Service Content (IA)


Receive and Audit Inventory (SS)


Employee e-learning (C)

From here we can draw an initial AOD (subsystem), highlighting the major business functions and their interconnections.

click to expand
Figure 4-4: IFBs architecture overview diagram (subsystem)

Step 2B - Seed the AOD with large reusable assets

Given the AOD (subsystem), it is once again possible to show the mapping (coverage) of the matched large reusable asset.

click to expand
Figure 4-5: AOD (subsystem) highlighting the coverage of the Portal composite pattern

This same information is shown in Table 4-4.

Table 4-4: Subsystems/use cases covered by the PCP (in red)

click to expand

Since the matched large reusable asset is the Portal composite pattern, as a final step in validating the coverage we can look at the Application patterns associated with the "covered" functionality to be sure it is consistent with the PCP. [2]

click to expand
Figure 4-6: Validating Application patterns for function subsystems included within the PCP

Step 2C - Identify and apply patterns for each AOD delta requirement

Next, the delta requirements must be addressed—first identifying the core business and/or integration patterns involved for each requirement, and then identifying the specific Application patterns.

click to expand
Figure 4-7: Business and Integration patterns for delta requirements

Table 4-5 describes the Application pattern selection for each of the delta requirements.

Table 4-5: Summary of Application patterns for delta Business and Integration patterns

e-Learning System

C::Managed Collaboration—Due to workflow directed collaboration.

Job Solicitation

C::Store and Retrieve—Simple document publishing

Apply for Job

  • SS::Directly Integrated Single Channel—Single delivery channel and monolithic application

  • AccI::Pervasive Device Access

Review and Guide Schedule

  • SS::Directly Integrated Single Channel—Multiple delivery channels, but can be handled via single presentation server (in other words, Portal)

  • AccI::Pervasive Device Access

Generate Schedule

SS::Directly Integrated Single Channel—Single delivery channel and monolithic application

Manage Tasks

SS::Directly Integrated Single Channel—Single delivery channel and monolithic application

Review and Perform Tasks

  • SS::Directly Integrated Single Channel—Multiple delivery channels, but can be handled via single presentation server (in other words, Portal)

  • AccI::Pervasive Device Access

Receive and Audit Inventory

  • SS::Router—Multiple delivery channels requiring multiple presentation servers

  • AccI::Pervasive Device Access

User Management

SS::Directly Integrated Single Channel—Single delivery channel and monolithic application

Finally, these Application patterns can be shown in the AOD (Figure 4-8 on page 185).

click to expand
Figure 4-8: Application patterns shown in the AOD

4.4.1 Transition to AOD (logical nodes)

Step 2D - Transition the AOD from subsystem view to logical node view

The next step is to drive down to the runtime pattern level for the solution. Once again, we have seeded the biggest chunk of the AOD (logical nodes) from the corresponding work product of the matched large reusable asset. Figure 4-9 on page 186 shows a slightly customized PCP runtime pattern used to seed the AOD (logical nodes).

click to expand
Figure 4-9: AOD (logical nodes) seeded from the customized PCP runtime pattern

Once the initial AOD (logical nodes) is established, each of the delta application patterns can have their individual runtime patterns analyzed to determine how to integrate it within the developing solution. Figure 4-10 on page 187 illustrates adding the wireless gateway node to the AOD and overlaying the AccI::Pervasive Device Access runtime pattern.

click to expand
Figure 4-10: Adding Pervasive Device Access support

Figure 4-11 demonstrates adding an integration server to support the runtime for the SS::Router application pattern.

click to expand
Figure 4-11: Adding integration server support

Figure 4-12 on page 188 represents the complete runtime.

click to expand
Figure 4-12: Final AOD (logical nodes) for IFB

Table 4-6 depicts the additional decisions made in coming up with the final AOD shown in Figure 4-12.

Table 4-6: Summary of decisions for additional logical nodes to support requirements

Functional or Non-Functional requirement

Architecture Decision (supporting logical nodes))

eLearning System

Supported with Learning Server node

Inventory System (multiple delivery channels)

Supported with Integration Server node


Moved Web server to internal network and added Security proxy node

Presentation server access to external content

Supported with Reverse proxy node in DMZ

Step 2F - Conduct technical walkthroughs to ensure that functional requirements are met

Here we validate the completeness of the logical solution by walking through each use case. Table 4-7 on page 189 provides the steps for the Update Personnel Record use case. The paths associated with each step are highlighted on Figure 4-13 on page 189. Note that this specific walkthrough highlights the fact that there should be direct connections between both the presentation and collaboration servers and the internal enterprise (PeopleSoft HR system).

Table 4-7: Associate update personnel information use case flow



Comments on Diagram


An Associate enters People Management Solutions via the Dynamic Workplaces Portal

Standard login and navigation from a browser client to the ODW.


The Associate reviews his or her personnel information

The presentation server utilizes a connector to the HR system providing the key data items (appropriately filtered for a specific Associate) on the ODW desktop.


The Associate chooses to update his or her address



A notification is posted to the Operational Manager and the HR system

The same connector interface permits updates to specific fields, again based on role and specific user (standard notification behavior of HR system for data field updates).


The HR system posts an update notification to the Associate

Standard notification behavior of HR system for data field updates

click to expand
Figure 4-13: Walkthrough for the Update Personnel Records use case

[2]Portal composite pattern

 < Day Day Up > 

Architecting Portal Solutions
Architecting Portal Solutions: Applications Development
ISBN: 0738498645
EAN: 2147483647
Year: 2003
Pages: 82
Authors: IBM Redbooks

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net