Boundary Class

Definition

A boundary class intermediates between the interface and something outside the system. Boundary classes insulate the system from changes in the surroundings (for example, changes in interfaces to other systems and changes in user requirements), keeping these changes from affecting the rest of the system.

A system can have several types of boundary classes:

User interface classes—Classes that intermediate communication with human users of the system.

System interface classes—Classes that intermediate communication with other systems. A boundary class that communicates with an external system is responsible for managing the dialog with the external system; it provides the interface to that system for the system being built.

Device interface classes—Classes that provide the interface to devices which detect external events.  These boundary classes capture the responsibilities of the device or sensor.

Role:

A boundary class is used to model interaction between the system's surroundings and its inner workings. Such interaction involves transforming and translating events and noting changes in the system presentation (such as the interface).

Entity Class

Definition

Entity objects represent the key concepts of the system being developed. Entity classes provide another point of view from which to understand the system, because they show the logical data structure. Knowing the data structure can help you understand what the system is supposed to offer its users.

Frequent sources of inspiration for entity classes are the:

- Glossary (developed during requirements)

- Business-Domain Model (developed during business modeling, if business modeling has been performed)

- Use-case flow of events (developed during requirements)

- Key abstractions (identified in Architectural Analysis)

Role:

Entity classes represent stores of information in the system. They are typically used to represent the key concepts that the system manages.

Control Class

Definition

Control classes provide coordinating behavior in the system. The system can perform some use cases without control classes by using just entity and boundary classes.

Control classes provide behavior that:

- Is surroundings-independent (does not change when the surroundings change).

- Defines control logic (order between events) and transactions within a use case.

- Changes little if the internal structure or behavior of the entity classes changes.

- Uses or sets the contents of several entity classes, and therefore needs to coordinate the behavior of these entity classes.

- Is not performed in the same way every time it is activated (flow of events features several states).

Role:

- A control class is a class used to model control behavior specific to one or more use cases. Control objects (instances of control classes) often control other objects, so their behavior is of the coordinating type. Control classes encapsulate use-case-specific behavior.

- Control classes can contribute to understanding the system, because they represent the dynamics of the system, handling the main tasks and control flows.

Communication Diagrams VS. Sequence Diagrams

Communication Diagrams

1. Show relationships in addition to interactions

2. Better for visualizing patterns of collaboration

3. Better for visualizing all of the effects on a given object

4. Easier to use for brainstorming sessions

Sequence Diagrams

1. Show the explicit sequence of messages

2. Better for visualizing overall flow

3. Better for real-time specifications and for complex scenarios

Analysis VS. Design

Analysis

1. Focus on understanding the problem

2. Idealized design

3. Behavior

4. System structure

5. Functional requirements

6. A small model

Design

1. Focus on understanding the solution

2. Operations and attributes

3. Performance

4. Close to real code

5. Object lifecycles

6. Nonfunctional requirements

7. A large model

Architecture

Definition:

Software architecture encompasses a set of significant decisions about the organization of a software system.

Architecture = Elements + Form + Rationale.

Rationale is essential for justifying a good architecture.

Patterns are the guidelines for assembling elements in some form. We will discuss patterns in the architecture modules.

4+1 View Model

System Behavior

System behavior is how a system acts and reacts.

System behavior is captured in use cases.

Activity Diagram

- An activity diagram in the Use-Case Model can be used to capture the activities in a use case.

- It is essentially a flow chart, showing flow of control from one activity or action to another.