Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Architectural Modeling


September 1999: Thinking Objectively: Architectural Modeling

SIDEBAR: Recommended Reading

These days it seems like everything is “architecture-centric” or “architecture-driven,” but what does that really mean? Why is architecture important to you? How does architectural modeling fit into your overall development process? It’s likely that your organization has been struggling with these questions for years, and I hope I can shed some light on how architectural modeling works in the real world. Although this column is targeted at organizations using object or component technology to develop systems, the material is high-level enough to work in any environment—your development deliverables may change, but the fundamentals remain the same.

Figure 1: The Model Process Pattern

I’ll start with the basics of the modeling process, captured in the Model process pattern depicted in Figure 1. It is based on David Taylor’s “T” technique, in which enterprise and organizational modeling efforts, forming the top bar of the “T,” drive detailed and project modeling efforts, each of which form the trunk of the “T.” This pattern shows that there are several different styles of modeling that work in both a top-down and a bottom-up fashion. The Model process pattern adds greater detail to Taylor’s original approach.

Figure 1 shows what I consider the 10 styles of modeling—enterprise modeling, four types of architectural modeling, four types of detailed modeling, and requirements modeling. It also shows that there are two fundamental levels of modeling, organizational level and project level. Let’s explore each level of modeling in detail. Table 1 summarizes the inputs and outputs of each modeling style—although many of the artifacts are similar, their level of detail and how they are used change between styles.

Table 1: The Artifacts of Object-Oriented Modeling
INPUT PROCESS OUTPUT

  • Existing "Enterprise Models"

  • Glossary
Enterprise Modeling

  • Enterprise Model
    - Use-Case Model
    - Business Process Model
    - Change Case Model
  • Glossary

  • Enterprise Model

  • Glossary
Organization-Level Domain Architectural Modeling

  • Domain Architectural Model
    - Component Model
    - Sequence Diagram(s)
  • Glossary

  • Domain Architectural Model

  • Enterprise Model

  • Glossary
Organization-Level Technical Architectural Modeling

  • Technical Architectural Model
    - Component Model
    - Infrastructure Model
    - Deployment Model(s)
    - Framework Model(s)
    - Sequence Diagrams
  • Glossary

  • Organization-Level Domain Architeture Model

  • Requirements Model

  • Glossary
Organization-Level Domain Detailed Modeling

  • Class Model(s)
  • Sequence Diagrams
  • Collaboration Diagram(s)
  • Statechart Diagram(s)
  • Activity Diagram(s)
  • Physical Persistence Model
  • Glossary

  • Organization-Level Technical Architectural Model

  • Requirements Model

  • Glossary
Organization-Level Technical Detailed Modeling

  • Class Model(s)
  • Sequence Diagrams
  • Collaboration Diagram(s)
  • Statechart Diagram(s)
  • Activity Diagram(s)
  • Framework Model
  • Glossary

  • Domain Architetural Model

  • Requirements Model

  • Glossary
Project-Level Domain Architecture Modeling

  • Project-Level Domain Architecture Model
    - Component Model
    - Sequence Diagram(s)
    - Change Proposal(s)
  • Change-Case Model
  • Glossary

  • Technical Architecture Model

  • Requirements Model

  • Glossary
Project-Level Technical Architecture Modeling

  • Project-Level Technical Architecture Model
    - Component Model
    - Deployment Model
    - Sequence Diagram(s)
    - Change-Case Proposal(s)
  • Glossary

  • Enterprise Model
Project-Level Requirements Modeling

  • Use Case Model
  • Supplementary Specifications
  • User Interface Mockups
  • Business Process Model
  • Business Rule Dictionary
  • Glossary

  • Project-Level Domain Architecture Model

  • Requirements Model

  • Glossary
Project-Level Domain Detailed Modeling

  • Class Model(s)
  • Sequence Diagrams
  • Collaboration Diagram(s)
  • Statechart Diagram(s)
  • Activity Diagram(s)
  • Physical Persistence Model
  • User Interface Model
  • Glossary

  • Project-Level Technical Architecture Model
  • Requirements Model
  • Glossary
Project-Level Technical Detailed Modeling

  • Class Model(s)
  • Sequence Diagrams
  • Collaboration Diagram(s)
  • Statechart Diagram(s)
  • Activity Diagram(s)
  • Framework Model
  • Glossary

The scope of organizational-level modeling is that of your entire company, the goals being to model your fundamental business with an enterprise model, the software that supports your business in a domain architectural model, and your system infrastructure in a technical architecture model. As shown in Figure 2, there are five styles of organizational-level modeling: enterprise modeling, domain architectural modeling, domain-detailed modeling, technical architectural modeling, and technical-detailed modeling.

Organizational-Level Modeling

Figure 2: Object-Oriented Architectural Modeling Overview

The goal of enterprise modeling is to model your organization’s high-level requirements so you understand the fundamentals of your organization and its environment. To do this, you must develop three artifacts: an enterprise-level use case model, an enterprise-level business process model, and an enterprise-level change case model. The use case model will depict the high-level business behaviors that your organization supports; for example, a bank would likely have use cases such as “Manage Money,” “Manage Loans,” and “Market Services.” Your business process model models the business processes that support the required business behaviors and the business environment that your organization operates in. For example, a bank’s business process model would show processes such as “Process Loan Payments” and “Bill for Loans,” depicting the information flowing into and out of those processes. The difference between the two artifacts is that your use case model focuses on what your organization does, whereas your process model focuses on how you do it—in other words, one focuses on requirements and the other on analysis. The third artifact is the change case model (see “Architecting for Change,” Thinking Objectively, May 1999), which documents likely changes to your business and technical environment, information you need to develop a robust architecture for your organization. It lets you develop models that easily support these potential changes.

In previous writings, I have said that a use case model is the primary artifact of enterprise modeling and have generally ignored business process modeling. I realize now that this is inconsistent with other advice that I’ve been given, namely that a single model isn’t sufficient for any one style of modeling because you need several views to accurately model something. No matter how thorough you are, no matter how comprehensive a model is, you simply can’t depict all of the information you need in one model. A use case model depicts a system’s behavioral requirements, a class model depicts the static organization of software, and a data model depicts how data will be stored in a relational database. You need three of these models at some point in the modeling process. In my series of columns about persistence, I claimed that enterprise-level data modeling is fundamentally flawed because it leads to software that doesn’t reflect the actual needs of its users (remember, it models data but not behavioral requirements). But the issue is more generic than this: you need several views and models to depict an aspect of your system. Table 1 shows that each of the 10 modeling processes produces several primary artifacts.

Domain modeling models how you intend to build the domain aspects of your organization’s software. The goal is to define a common domain software environment that all of your applications share, promoting consistency and reuse between applications. You achieve this through two processes: the first being domain architectural modeling that models your software’s static structure in the form of a large-scale component model, and sequence diagrams that model the dynamic interactions of components. The component model depicts the large-scale domain components—a bank would have components such as “Account,” “Customer,” and “Transaction”—that your applications collaborate with to support your business. The sequence diagrams map the behavioral logic of your use cases and the process logic of your business processes, at the enterprise level to the domain components in your domain architecture model. You can find information about this process in my book Process Patterns (Cambridge University Press, 1998), Ivar Jacobson’s Software Reuse (Addison-Wesley, 1997), and Component-Based Development for Enterprise Systems (Cambridge University Press, 1998) by Paul Allen and Stuart Frost.

The second process is domain detailed modeling, which, as the name implies, focuses on the detailed modeling of the domain components. Architecture modeling effort focuses on the components’ interface; the detailed modeling effort focuses on the components’ interior. Organization-level domain architectural modeling is typically a cross-project effort that your architecture team performs, whereas organization-level domain detailed modeling generally supports a project’s development efforts. Next month, I will discuss these kinds of management issues in greater detail.

In addition to domain modeling, you also need to do technical modeling, which models your organization’s technical or system infrastructure. The goal of technical modeling is to, once again, promote consistency and reuse between applications. There are also two styles of modeling: organization-level technical architectural modeling, which focuses on the overall structure of your technical infrastructure, and organization-level technical detailed modeling, which focuses on how the components and frameworks that make up your technical infrastructure will work. Many developers consider technical modeling the fun part of software development, because you get to define the plumbing of your software, although many make the mistake of ignoring domain architectural modeling. Your technical architecture will often describe your software security approach, how your system will be deployed, your persistence layer or framework, and your system audit component, to name a few. Because your technical architecture addresses a wide range of issues, you need several views. Use component models to show your organization’s technical components (such as your security and audit components), framework models to describe common frameworks (such as your persistence and user interface frameworks), and an infrastructure model to tie together the frameworks and components, typically using a layered approach.

Project-Level Modeling

You also need to understand the process of project-level modeling, which starts with project-level requirements modeling. Your requirements effort should flesh out a small portion of your enterprise model, likely working portions of one or more enterprise-level use cases as the scope of a project. This effort, in turn, drives your project-level domain architectural modeling and project-level technical modeling efforts. The goal of these two efforts is to understand how your new system fits into the existing domain and technical architectures of your organization, as well as to determine how your project will change to the existing architectures. As shown in Figure 2, your project-level architectural modeling efforts will often drive organization-level architectural and detailed modeling. Your architecture group will frequently need to make changes to its models to reflect the new needs of your project team.

Once you understand your application’s architecture, you perform project-level domain detailed modeling and project-level technical detailed modeling as needed. This is similar in concept to your organization-level detailed modeling efforts, except for a greater emphasis on the user interface model, and the fact that it models only a single project and not the entire organization.

Architecting for Success

Before concluding, I would like to make two very important points. First, as I noted earlier, the general processes and concepts remain the same, regardless of your implementation technology. If you are using structured technologies such as COBOL and relational databases or even active objects, you still need to perform these various styles of organization-level and project-level modeling. For structured technologies, you are likely to replace class models, sequence diagrams, and collaboration diagrams with structure charts, while for active objects you are likely to use collaboration diagrams in place of component models. The artifacts may change but the fundamental process remains the same. Second, Table 1 shows that a glossary is a key input and output of all modeling processes. By having a shared glossary, you increase the consistency between your development efforts and reduce the overall effort by reusing this artifact.

Architecture is critical to software development success, and your software process must reflect this. There are two flavors of architectural modeling, domain and technical, as well as two levels, organizational and project. Your architectural modeling efforts fit into a larger picture that includes both enterprise modeling and several styles of detailed modeling. Because each type of model only showed a small aspect of your overall system, you need several models to successfully describe your software. In short, architectural modeling is a complex endeavor that your organization must strive to understand. Next month, I will expand on the concepts presented here and discuss the management, cultural, and tool-based issues surrounding architectural modeling.

Recommended Reading

Business Engineering With Object Technology by David Taylor (John Wiley and Sons, 1995)

Designing Hard Software: The Essential Tasks by Douglas Bennett (Manning Publications Co., 1997)

The Rational Unified Process: An Introduction by Philippe Kruchten, (Addison-Wesley Longman 1999)

Software Architecture in Practice by Len Bass, Paul Clements, and Rick Kazman (Addison Wesley, 1998)

Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology by Scott W. Ambler, (Cambridge University Press, 1998)

Scott Ambler


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.