Dynamic modeling provides a view of a system in which control and sequencing are considered, either within an object (by means of a finite state machine) or between objects (by analysis of object interactions). This chapter addresses dynamic interaction between objects.

Dynamic interaction modeling is based on the realization of the use cases developed during use case modeling. For each use case, it is necessary to determine how the objects that participate in the use case dynamically interact with each other. The object structuring criteria described in Chapter 8 are applied to determine the objects that participate in each use case. This chapter describes how, for each use case, an interaction diagram is developed to depict the objects that participate in the use case and the sequence of messages passed between them. The interaction is depicted on either a communication diagram or a sequence diagram. A narrative description of the object interaction is also provided in a message sequence description. Please note that all references to system in this chapter are to the software system.

This chapter first describes object interaction modeling using communication diagrams and sequence diagrams before describing how they are used in dynamic interaction modeling. It then describes the details of the dynamic interaction modeling approach for determining how objects collaborate with each other. This chapter describes stateless dynamic interaction modeling, also referred to as basic dynamic interaction modeling.

This chapter describes key software design concepts that have shown their value over the years for the design of software architectures. First, object-oriented concepts are introduced, and objects and classes are described. Then there is a discussion of the role of information hiding in object-oriented design and an introduction to the concept of inheritance. Next, the concurrent processing concept and the concept of concurrent objects in concurrent applications are introduced. This is followed by an overview of software design patterns, software architecture, and the main characteristics of component-based systems. Finally, the concept of software quality attributes is discussed. Examples in this chapter are described in UML. An overview of the UML notation is given in Chapter 2.

Section 4.1 provides an overview of object-oriented concepts. Section 4.2 describes information hiding. Section 4.3 describes inheritance and generalization/ specialization relationships. Section 4.4 provides an overview of concurrent processing. Section 4.5 gives an overview of software design patterns, with the actual patterns described in subsequent chapters. Section 4.6 provides an overview of software architecture and the main characteristics of component-based systems. Finally, Section 4.7 gives an introduction to software quality attributes.

OBJECT-ORIENTED CONCEPTS

The term object-oriented was first introduced in connection to object-oriented programming and Smalltalk, although the object-oriented concepts of information hiding and inheritance have earlier origins. Information hiding and its use in software design date back to Parnas (1972), who advocated using information hiding as a way to design modules that were more self-contained and, hence, could be changed with little or no impact on other modules.

This chapter describes how the COMET software modeling and architectural design method is applied to the design of a component-based software architecture: an Emergency Monitoring System.

The problem description is given in Section 23.1. Section 23.2 describes the use case model for the Emergency Monitoring System. Section 23.3 describes the Emergency Monitoring System static model, covering static modeling of both the system context and entity classes. Section 23.4 describes dynamic modeling, in which communication diagrams are developed for each of the use cases. Section 23.5 describes the design model for the Emergency Monitoring System, which is designed as a layered architecture based on the Layers of Abstraction pattern combined with the client/service pattern and several architectural communication patterns. Section 23.6 describes software component deployment.

PROBLEM DESCRIPTION

An Emergency Monitoring System consists of several remote monitoring systems and monitoring sensors that provide sensor input to the system. The status of the external environment is monitored with a variety of sensors. Some of these sensors are attached to remote monitoring systems, which send regular status input that is stored at a monitoring service. In addition, from the sensor information, alarms are generated concerning undesirable situations in the external environment that require human intervention. Alarms are stored at an alarm service. Monitoring operators view the status of the different sensors and view and update alarm conditions.

USE CASE MODELING

This section describes the use case model for the Emergency Monitoring System. From the problem description, three actors are determined.

During analysis modeling, the problem is analyzed by breaking it down and studying it on a use case–by–use case basis. During design modeling, the solution is synthesized by designing a software architecture that defines the structural and behavioral properties of the software system. To successfully manage the inherent complexity of a large-scale software system, it is necessary to provide an approach for decomposing the system into subsystems and developing the overall software architecture of the system. After performing this decomposition, each subsystem can then be designed independently, as described in subsequent chapters.

Section 13.1 describes issues in software architectural design. To design the software architecture, it is necessary to start with the analysis model. Several decisions need to be made in designing the software architecture:

• Integrate the use case–based interaction models into an initial software architecture, as described in Section 13.2.

• Determine the subsystems using separation of concerns and subsystem structuring criteria, as described in Sections 13.3 and 13.4, respectively.

• Determine the precise type of message communication among the subsystems, as described in Section 13.5.

ISSUES IN SOFTWARE ARCHITECTURAL DESIGN

In the analysis of the problem domain and structuring a system into subsystems, the emphasis is on functional decomposition, such that each subsystem addresses a distinctly separate part of the system (as discussed in Section 13.3). The design goal is for each subsystem to perform a major function that is relatively independent of the functionality provided by other subsystems.

This chapter describes the design of software architectures for client/server systems. In these systems, a client is a requester of services and a server is a provider of services. Typical servers are file servers, database servers, and line printer servers. Client/server architectures are based on client/service architectural patterns, the simplest of which consists of one service and multiple clients. This pattern has several variations, which will be described in this chapter. In addition, certain decisions need to be considered about the design of client/server architectures, such as whether the server should be designed as a sequential or concurrent subsystem, what architectural structure patterns to use for the design of the client/server architecture, and what architectural communication patterns to use for interaction between the clients and the services.

This chapter differentiates between a server and a service. A server is a hardware/software system that provides one or more services for multiple clients. A service in a client/server system is an application software component that fulfills the needs of multiple clients. Because services execute on servers, there is sometimes confusion between the two terms, and the two terms are sometimes used interchangeably. Sometimes, a server will support just one service or perhaps more than one; on the other hand, a large service might span more than one server node. In client/server systems, the service executes on a fixed server node(s) and the client has a fixed connection to the server.

Object-oriented concepts are fundamental to software design. Object-oriented design refers to software systems that are designed using the concepts of information hiding, classes, and inheritance. Objects are instantiated from classes and are accessed through operations, which are also referred to as methods.

A class is designed using the information hiding concept to encapsulate different kinds of information, such as details of a data structure or state machine. These classes are originally determined during the object and class structuring phase of analysis modeling, as described in Chapter 8. In particular, this chapter describes the design of class interfaces and the operations provided by each class. This chapter also describes the use of inheritance in software design. An introduction to information hiding, classes, and inheritance was given in Chapter 4. As pointed out in Chapter 4, the term operation refers to both the specification and the implementation of a function performed by an object.

Section 14.1 gives an overview of the concepts, architectures, and patterns used in designing sequential object-oriented architectures. Section 14.2 describes important issues in the design of information hiding classes. Section 14.3 describes the design of the class interface and operations, as well as how they are determined from the dynamic model. The following sections describe the design of different kinds of information hiding classes: Section 14.4 describes the design of data abstraction classes, which encapsulate data structures; Section 14.5 describes the design of state machine classes, which encapsulate finite state machines; Section 14.6 describes the design of graphical user interaction classes, which hide details of the user interface; and Section 14.7 describes the design of business logic classes, which encapsulate business rules.

SOFTWARE MODELING

Modeling is used in many walks of life, going back to early civilizations such as Ancient Egypt, Rome, and Greece, where modeling was used to provide small-scale plans in art and architecture (Figure 1.1). Modeling is widely used in science and engineering to provide abstractions of a system at some level of precision and detail. The model is then analyzed in order to obtain a better understanding of the system being developed. According to the Object Modeling Group (OMG), “modeling is the designing of software applications before coding.”

In model-based software design and development, software modeling is used as an essential part of the software development process. Models are built and analyzed prior to the implementation of the system, and are used to direct the subsequent implementation.

A better understanding of a system can be obtained by considering it from different perspectives (also referred to as multiple views) (Gomaa 2006; Gomaa and Shin 2004), such as requirements models, static models, and dynamic models of the software system. A graphical modeling language such as UML helps in developing, understanding, and communicating the different views.

This chapter introduces object-oriented methods and notations, an overview of software modeling and architectural design, and an introduction to model-driven architecture and UML. The chapter then briefly describes the evolution of software design methods, object-oriented analysis and design methods, and concurrent, distributed, and real-time design methods.

OVERVIEW

This book describes a use case–driven UML-based method for the modeling and design of software architectures, including object-oriented software architectures, client/server software architectures, service-oriented architectures, component-based software architectures, concurrent and real-time software architectures, and software product line architectures. The book provides a unified approach to designing software architectures and describes the special considerations for each category of software architecture. In addition, there are four case studies, a client/server banking system, a service-oriented architecture for an online shopping system, a distributed component-based emergency monitoring system, and a real-time automated guided vehicle system.

This book describes a UML-based software modeling and design method called COMET (Collaborative Object Modeling and Architectural Design Method). COMET is a highly iterative object-oriented software development method that addresses the requirements, analysis, and design modeling phases of the object-oriented development life cycle.

The book is intended to appeal to readers who wish to design software architectures using a systematic UML-based method that starts from requirements modeling with use cases, through static and dynamic modeling, to software design based on architectural design patterns.

WHAT THIS BOOK PROVIDES

Various textbooks on the market describe object-oriented analysis and design concepts and methods. This book addresses the specific needs of designing software architectures. It addresses UML-based design of software architectures, starting with use cases for requirements modeling, static modeling with class diagrams, and dynamic modeling with object interaction analysis and state machine modeling, through software design with architectural design patterns.

A service-oriented architecture (SOA) is a distributed software architecture that consists of multiple autonomous services. The services are distributed such that they can execute on different nodes with different service providers. With a SOA, the goal is to develop software applications that are composed of distributed services, such that individual services can execute on different platforms and be implemented in different languages. Standard protocols are provided to allow services to communicate with each other and to exchange information. In order to allow applications to discover and communicate with services, each service has a service description, The service description defines the name of the service, the location of the service, and its data exchange requirements (Erl 2006, 2009).

A service provider supports services used by multiple clients. Usually, a client will sign up for a service provided by a service provider, such as an Internet, email, or Voice over Internet Protocol (VoIP) service. Unlike client/server architectures, in which a client communicates with a specific service provided on a fixed server configuration, this chapter describes SOAs, which build on the concept of loosely coupled services that can be discovered and linked to by clients (also referred to as service consumers or service requesters) with the assistance of service brokers.

The notation used for the COMET method is the Unified Modeling Language (UML). This chapter provides a brief overview of the UML notation. The UML notation has evolved since it was first adopted as a standard in 1997. A major revision to the standard was made in 2003, so the current version of the standard is UML 2. The previous versions of the standard are referred to as UML 1.x.

The UML notation has grown substantially over the years, and it supports many diagrams. The approach taken in this book is the same as Fowler's (2004), which is to use only those parts of the UML notation that provide a distinct benefit. This chapter describes the main features of the UML notation that are particularly suited to the COMET method. The purpose of this chapter is not to be a full exposition of UML, because several detailed books exist on this topic, but rather to provide a brief overview. The main features of each of the UML diagrams used in this book are briefly described, but lesser-used features are omitted. The differences between UML 2 notation and UML 1.x notation are also briefly explained.

UML DIAGRAMS

The UML notation supports the following diagrams for application development:

• Use case diagram, briefly described in Section 2.2.

• Class diagram, briefly described in Section 2.4.

• Object diagram (an instance version of the class diagram), which is not used by COMET.

• Communication diagram, which in UML 1.x was called the collaboration diagram, briefly described in Section 2.5.1.

• […]

This chapter describes the design of concurrent and real-time software architectures. Real-time software architectures are concurrent architectures that usually have to deal with multiple streams of input events. They are typically state-dependent, with either centralized or decentralized control. Thus, the design of finite state machines, as described in Chapter 10, state-dependent interaction modeling, as described in Chapter 11, and the control patterns, as described in this chapter, are very important in the design of real-time software architectures.

Section 18.1 describes concepts, architectures, and patterns for designing concurrent and real-time software architectures. Section 18.2 describes the characteristics of real-time systems. Section 18.3 describes control patterns for real-time software architectures. Section 18.4 describes the concurrent task structuring criteria. Section 18.5 describes the I/O task structuring criteria, and Section 18.6 describes the internal task structuring criteria. Section 18.7 describes the steps in developing the concurrent task architecture. Section 18.8 describes designing the task interfaces using task communication and synchronization. Section 18.9 describes documenting task interface and behavior specifications. Section 18.10 describes concurrent task implementation in Java using threads.

CONCEPTS, ARCHITECTURES, AND PATTERNS FOR CONCURRENT AND REAL-TIME SOFTWARE ARCHITECTURES

An important activity in designing real-time software architectures is to design concurrent objects, which are referred to as concurrent tasks in this chapter. Chapter 14 described the design of passive objects, which do not have threads of control. Concurrency concepts were introduced in Chapter 4.

In distributed component-based software design, the component-based software architecture for the distributed application is developed. The software application is structured into components, and the interfaces between the components are defined. To assist with this process, guidelines are provided for determining the components. Components are designed to be configurable so that each component instance can be deployed to a different node in a geographically distributed environment.

Components are initially designed using the subsystem structuring criteria described in Chapter 12. Additional component configuration criteria are used to ensure that components are indeed configurable – in other words, that they can be effectively deployed to distributed physical nodes in a distributed environment.

Section 17.1 describes concepts, architectures, and patterns for distributed component-based software architectures. Section 17.2 describes the steps in designing distributed component-based software architectures. Section 17.3 describes the concepts and design of composite subsystems and components. Section 17.4 describes how components can be modeled and designed with UML. Section 17.5 describes component structuring criteria for structuring a distributed application into configurable distributed components. Section 17.6 describes group communication patterns, including Broadcast Message Communication and Subscription/Notification Message Communication patterns. Finally, Section 17.7 describes application deployment.

CONCEPTS, ARCHITECTURES, AND PATTERNS FOR COMPONENT-BASED SOFTWARE ARCHITECTURES

In Chapter 12, the term component was introduced in a general way. This chapter describes the design of distributed components as used in distributed component-based software architectures. It describes the component structuring criteria for designing components that can be deployed to execute on distributed platforms in a distributed configuration.

After defining the use cases and developing a static model of the problem domain, the next step is to determine the software objects in the system. At this stage, the emphasis is on software objects that model real-world objects in the problem domain.

Software objects are determined from the use cases and from the static model of the problem domain. This chapter provides guidelines on how to determine the objects in the system. Object structuring criteria are provided, and the objects are categorized by using stereotypes. The emphasis is on problem domain objects to be found in the real world and not on solution domain objects, which are determined at design time.

The static modeling described in Chapter 7 was used to determine the external classes, which were then depicted on a software system context class diagram. These external classes are used to help determine the software boundary classes, which are the software classes that interface to and communicate with the external environment. The entity classes and their relationships were also determined during static modeling. In this chapter, the objects and classes needed in the software system are determined and categorized. In particular, the focus is on the additional software objects and classes that were not determined during the static modeling of the problem domain.

The static relationship between classes is considered in the static model, as described in the previous chapter, and the dynamic relationship between the objects is considered in the dynamic model, as described in Chapters 9, 10, and 11.