Define application architectures with Rational Software Architect: Part 1. Envisioning the architecture

This series presents techniques for creating models to specify and communicate the architecture of software-intensive systems. It illustrates the elaboration of the Online Catering architecture for a fictional company, Yummy Inc. Using an iterative approach, it describes the key architectural activities that are necessary to specify a software-intensive system with IBM® Rational® Software Architect (RSA). In part 1 of the series, we focus on typical tasks to outline the architecture and to align the technical vision to development needs. Part 2 will describe how the architecture is iteratively refined using RSA. Both articles assume that readers are familiar with methodologies based on iterative development.

Jean-Louis Marechaux (jl.marechaux@ca.ibm.com), Software Engineer, IBM

Photo of Jean-Louis MarechauxJean-Louis Maréchaux works as a software engineer for IBM Rational in Canada. His main areas of interest are software architecture, Java EE technologies, SOA, and Agile software development practices. He published several articles on these subjects in the past and contributed to the Practical Guide to Distributed Scrum in 2010. Before joining the Rational group, Jean-Louis worked as an IT architect for the IBM Global Services group and other IT organizations, where he was involved in application architecture and design. You can contact him at jl.marechaux@ca.ibm.com.



11 October 2011

Also available in Chinese Russian Vietnamese

Introduction

There are many different methodologies that provide a set of customizable best practices to help businesses reliably deliver quality software. Agile software development is now mainstream and one of its core principles is to adopt iterative and incremental methods. The focus of this article is on concrete activities from a software architect perspective, which assumes that you are already proficient in agile practices and iterative development (see the Resources section for more information about IBM agility@scale, IBM Practices, OpenUP, and Rational Unified Process).

The main purpose of this article is to illustrate how Rational Software Architect 8 (hereinafter called RSA) can assist in architectural thinking and documentation. RSA is a collaborative design platform for delivering high-quality architecture. RSA helps you define models at various levels of abstraction, and it can be leveraged to support industry best practices in software engineering.


Architectural analysis: Envisioning and evolving the architecture

Architectural analysis is a set of activities to build and improve the software architecture of a system. When conducted iteratively, this architectural thinking helps uncover and address issues during software development without requiring significant up-front architectural effort. Architectural analysis activities are crucial for every software-intensive system. Despite what dogmatic agile development coaches might say, there is no successful software development without architectural analysis.

Architectural analysis occurs at two different places. First, at the very beginning of a project, which is often referred to as iteration 0, or sprint 0. During this initial iteration, the software architect wants to envision the architecture based on significant known requirements and on architectural constraints, decisions, and objectives. Architectural envisioning is not a long and cumbersome activity. Depending on the complexity of your system, it can take days or even hours within a time-boxed iteration.

As a software architect, you typically follow these steps to outline the target architecture of your software-intensive system:

  1. Identify significant requirements: the key functional and non-functional requirements with a significant impact on the architecture
  2. Define the candidate architecture: the high-level architecture of the system based on architectural constraints and goals
  3. Define the initial deployment model: the topology representing the deployment nodes of the system
  4. Define the domain model: the key business entities and their relationships.

E-book available

Download the e-book from the author's blog post "Evolutionary architecture with Rational Software Architect v8"

Once you have completed the initial technical vision, you can build your system on sound architectural foundations. In each iteration, the development team uncovers new technical challenges and new opportunities for improvement. Those playing the role of the software architect have new architectural decisions to make. It is why continuous architectural improvement is the key to software-intensive system development. Architecture is not something you create up front and leave alone. Architectural thinking is part of software development from the beginning to the end of a project.

The following architectural activities are typically performed during development iterations:

  1. Refine architectural mechanisms: Technical concepts to satisfy architecturally significant requirements identified in the first step.
  2. Refine design elements: The architecturally significant design elements
  3. Refine the deployment architecture: The deployment units and topologies

The iterative activities are described in the second part of this series.

Figure 1. Iterative and incremental architectural analysis
The architectural analysis, its tasks and its activities

Although we do not cover review activities in this article, any experienced practitioner knows that the architecture must be validated regularly to verify that it is consistent with the requirements and the needs of the team. So you need an effective mechanism to capture and communicate the architecture to different stakeholders.


Describe architectures by using views

A proven and widely adopted approach of describing architectures is the use of views and viewpoints. A view is a representation of a whole system from the perspective of a set of concerns or interests. From the viewpoint of a stakeholder, a view addresses all the critical or important aspects of the system. As a system typically has many stakeholders, several views are needed to cover all the stakeholders concerns.

In 1995, Philippe Kruchten proposed a model for describing the architecture of software-intensive systems: the 4+1 view model of software architecture (For more information, see Resources). Most of the concepts in the "4+1" model have been included in development processes, such as the IBM Rational Unified Process (RUP) or OpenUP. More recently, the IEEE 1471 standardized the definition of a view to address the concerns of various stakeholders of a software architecture (See the Resources section for more information about IEEE 1471-2000 / ISO 42010).

In the original "4+1" model, five views are used to provide a comprehensive description of a system, as shown in Figure 2.

Figure 2. 4+1 architectural view model
All the views are related to the scenarios in the 4 plus 1 model

In the 4+1 model, each view addresses the concerns of a specific set of stakeholders, allowing various stakeholders to find what they need in the software architecture. The model can be tailored. Depending on your project complexity, you might only need a subset of the proposed views. The model is also extensible, so you might want to add other views to describe your architecture from a different viewpoint. Note that additional views can usually be folded into existing views as sub categories.

In Table 1, each row represents a view with its corresponding audience, area, and model.

Table 1. Architecture views
ViewAudienceAreaModel
LogicalDesignersUse-case realizationAnalysis model
Design model
ProcessIntegratorsPerformance
Scalability
Concurrency
Deployment model
Design model
ImplementationProgrammersSoftware componentsImplementation model
DeploymentDeployment managersPhysical nodesDeployment model
ScenariosEveryoneFunctional requirementsUse-case model
User stories
Business processes
Data
(optional or part of logical view)
Data specialists
Data administrators
Data persistenceData model

Note:
Traditionally, the process view is not that important for an application because the platform deals natively with the threading aspects. Nevertheless, you can choose to document some of the concurrency issues in a deployment model, and some of the communication mechanisms (synchronous versus asynchronous) in a design model.


Preparing the workspace

Before you start RSA, make sure that you have installed the minimum set of tools to support the work of the architect. Using the Installation Manager, verify that the "Architect – Standard" option is checked, as shown in figure 3. This pre-defined profile enables the UML and topology modeling capabilities that you need to perform the tasks presented in this article.

Figure 3. Standard architect profile
The installation profile options during installation

The next step is to create a new workspace. To do it, launch RSA and specify a storage directory (Figure 4).

Figure 4. The Workspcae Launcher window
The launcher to crate a new workspace: Yummy2011

RSA provides many different perspectives to customize the initial set and layout of views in the Workbench window. Verify that the Modeling perspective is open before going further (Figure 5).

Figure 5. The Open Perspective window
The Open Perspective window

RSA comes with different pre-defined UML model templates. In the Modeling Perspective, you can add as many models as you need in order to document the architecture of your system (Figure 6).

Figure 6. UML model templates
List of analysis and design model templates

Each template is dedicated to a specific architectural purpose. Typically, to define each aspect of the system (remember the "4+1" view model), you need the Use-Case, Analysis and Design models. In our example, we also create a sketch for the architecture vision and a topology to specify the deployment target environment. So Yummy Inc. workspace contains the following models (Figure 7). Each one is based on a different RSA template.

Figure 7. Models that describe the architectural views for the Online Catering system
The tree view of the Online catering models

Note that we could have decided to use other types of models available in the RSA templates, such as the BPMN model (business process) or the Services model (SOA).

Now that your RSA workspace is ready, you need to perform several activities that we mentioned previously. Let's illustrate how RSA can assist you in your step-by-step architectural analysis.


Envision the architecture

As a software architect, you need to envision the initial architecture and outline the architectural decisions that guide development and testing. This effort relies on gathering experience gained in similar systems or problem domains to constrain and focus the architecture. You conclusions should yield information to communicate the architecture to the team.

Identify significant requirements

One of the first tasks you will be doing during the architectural envisioning is to identify the requirements that are significant for the architecture. As an architect, your role is to ensure that the target architecture is appropriate to realize user needs. So you need to review the use-cases, the business processes, or the user stories to identify the ones that may have a significant impact on the architecture. Experienced architects work closely with project managers or product owners to educate them about the architectural impacts of items in the backlog. They influence how the backlog is prioritized to address technical uncertainties as soon as possible.

In RSA, the Use-case model contains the identified requirements for Yummy Inc. (Figure 8).

Figure 8. Requirements for the Online Catering system
The Ordering Menus requirement package and its elements

There is no universal rule to identify significant requirements. It depends on your environment, your technical framework, and your project team. Requirements with a huge impact on the architecture for a team can seem trivial for another team. A requirement to display a simple list of items will probably not influence your architecture too much. But if the requirement is to obtain the items for a business partner through an asynchronous service call, you must make sure that you have the plumbing in your architecture to support that need.

In our Yummy Inc. example, the model is subdivided into functionally-oriented packages. Each package contains the related use-cases and actors (cross-cutting actors are grouped in the versatile package). A use-case diagram illustrates the requirement (Figure 9). Of course, the same information could have been captured in a business process diagram or a user story.

Figure 9. The Order Menus use-case diagram
The ordering menus use cases and the actors involved

Define the candidate architecture

After the significant requirements have been identified, the software architect creates an overview of the architecture. Nowadays, we rarely develop systems from scratch. We enrich existing applications, we modernize legacy systems, and we reuse and assemble assets. The architect leverages past experience with similar systems and makes sure that goals and constraints are considered. The candidate architecture takes into account the functional requirements (use-cases, stories, business processes) but also the non-functional requirements (availability, performance, scalability…) of the system.

In our example, we have chosen an N-tier architecture (Figure 10) where the application is web-based, but is also accessed through web services from different client types (see Resources for more information about the multi-tiered applications)

Note that this technology diagram (Figure 10) created in RSA is quite simple at this stage, and can be completed in a short brainstorming session. The sketch shows the major components involved and the technology stack identified to develop the solution.

Figure 10. N-tier architecture sketch for the Online Catering system
The sketch for the Online Catering application at Yummy Inc.

Larger view of Figure 10.

Define the initial deployment model

Using the overview of the architecture sketched before, a software architect can now draw the big picture of the deployment model. It depicts the major software and hardware components and how they interact at a high level. The deployment diagram takes into account constraints of the deployment environment, and is a great communication vehicle for the development and infrastructure teams to share information between groups.

The UML specification provides a set of elements to define deployment models. However, the deployment part of UML has proven to be limited in terms of capabilities. As a result, it has not been widely adopted by the industry, even among intensive UML users. RSA provides a rich set of tools to define deployment topologies (logical, physical, and deployment instances). RSA topologies are really powerful where the UML deployment models fall short: Simplicity, reuse, and traceability (see the Resources for the further information about deployment topologies)

The deployment diagram (Figure 11) shows the different hardware components required to host the application. RSA comes with a bank of images to make your diagram more meaningful, and allows you to add your own images to represent specific model elements.

Figure 11. Deployment nodes for the Online Catering system
The deployment nodes for the online catering application

Larger view of Figure 11.

Define the domain model

For business applications, an initial domain model helps the development team understand the key business entities and their relationships. The software architect can obtain the information from a variety of sources like functional requirements, stories or business processes.

In RSA, a simple way to capture the business entities is by leveraging the analysis profile. This profile contains three stereotypes that you can apply to UML elements (Figure 12).

Figure 12. UML stereotypes
The three visual representations of the analysis stereotypes

The Boundary stereotype is used to represent a class that acts as an interface to the system. The Control class describes a component that exercises control over other classes. The Entity stereotype designates a class that carries data.

At this stage, you only care about the data so only the entity stereotype is used. It is important to capture the overall vocabulary of the system to implement. It is the starting point of the Analysis Model that you create in the next step.

The Analysis Model template provided by RSA is pre-structured and comes with a special package named Perspective overviews to collect information related to key concepts (Figure 13).

Figure 13. Perspective overviews for the Online Catering system
Perspective overviews for the Online Catering system

alt= The analysis package for the online catering application

As a software architect, you can use a simple class diagram (containing the key business entities) to capture the first draft of domain model using analysis stereotypes (Figure 14).

Figure 14. Online Catering domain model
Online catering domain elements and their relationships

Other options are available to define your domain model in RSA. First, you can choose to create a simple sketch representing the business entities (Figure 15).

Figure 15. Domain model sketch for the Online Catering system
A simple sketch to depict the Online catering domain model

In RSA, sketches elements can be converted to UML elements when you need a more formal notation, and you keep traceability between the generated UML and the initial sketch. Another option is to create a data diagram. In RSA, you can create tables, columns and keys in a diagram representing your data, or you can connect to your database to import an existing schema. Which option to choose to define you domain model really depends on your environment and on the way the project team works. There is no perfect solution but there is surely one that is best for you.


Summary

At this stage, you have defined the vision for the architecture of your software-intensive system. You know which views are useful to your stakeholders, you have identified the requirements with a significant impact on your technical solution, and you have outlined the target architecture accordingly. In a short time box (iteration 0), you have captured in RSA the key information related to technologies, deployment and domain models.

In part 2 of this series, you will see how to use RSA to refine the architecture of your software-intensive system.


Download

DescriptionNameSize
Yummy RSA modelsYummy2011.zip84KB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=764253
ArticleTitle=Define application architectures with Rational Software Architect: Part 1. Envisioning the architecture
publish-date=10112011