CLO-1 Bugden Chapter (1-5)

Summary: Key Concepts of Design Thinking

1. Dual Meaning of Design:

o Noun: A design refers to a plan for constructing a physical

artifact or performing a process. Examples include blueprints
for boats or recipes for cakes.

o Verb: To design refers to the creative process of generating a

plan, emphasizing the act of problem-solving and innovation.

2. Perspectives on Design:
Design thinking can be categorized into three perspectives:

o Design as Styling: Focuses on the aesthetic and usability aspects (e.g., user interfaces,
fashion, product appearance).

o Design as Planning: Involves strategic organization of resources and processes (e.g.,

project planning, testing strategies).

o Design as Adaptation: Centers on creating new solutions by reusing and modifying

existing ideas and models (e.g., adapting database designs or combining architectural
styles).

3. Key Characteristics of Designing:

o Descriptive Nature: Designs often involve diverse forms of descriptions, such as

diagrams, text, or mathematical notation.

o Creativity and Envisioning: Requires imagining how something might work and devising
methods to achieve it.

o Balance: A good design must balance functionality, efficiency, user appeal, and
adaptability.

4. Software Design Considerations:

o Interdependence: The way a design plan is created influences the design process, and
vice versa.

o Challenges: Software design involves tackling ill-structured problems (ISPs) with no clear
true/false answers, demanding creativity and foresight.

o Technical Debt: Decisions in design affect future software evolution, requiring careful
thought to avoid unsustainable practices.
5. Goal of Design Thinking:

o To creatively solve problems and produce effective, innovative solutions.

o For software, this involves ensuring designs are practical, adaptable, and user-friendly
while avoiding inefficiencies and "software lemons."

• Characteristics of ISPs
o There is no definitive formulation of an ISP
o ISPs have no stopping rule.
o Solutions to ISPs are not true or false, but good or bad.
o There is no immediate and no ultimate test of a solution to an ISP.
o Every ISP is essentially unique.
Design Activities
1. Postulate a Solution: Predict and organize how a solution may address the need.
2. Build a Model: Create a design model as a representation of the solution.
3. Evaluate the Model: Assess the model against requirements and refine iteratively.
4. Elaborate for Realization: Develop the model into a detailed plan for implementation.
Design Process Characteristics
• Iterative: Requires cycles of refinement and backtracking as issues arise or objectives shift.
• Uncertain: Early designs may fail or be suboptimal, revealing new challenges or opportunities.
• Complex: Designers often manipulate physical and abstract elements simultaneously, such as
processes in software.
Managing design processes
1. Human Cognitive Limitations
• Designers face challenges in handling multiple complex design elements due to these cognitive
limits, necessitating tools and strategies to manage complexity.
2. Abstraction as a Core Concept
• Abstraction simplifies design by focusing on relevant details while omitting unnecessary
specifics.
• It reduces cognitive load, enabling designers to conceptualize systems more effectively.
3. Designing Systems
• System design involves creating models that address specific needs from requirements.
• Early design decisions (e.g., architectural style) often involve trade-offs based on criteria like
speed, functionality, and future adaptability.
4. Decision-Making in Design
• Designers balance competing priorities, such as functional requirements and technical debt.
• Fitness for purpose is the ultimate criterion, focusing on the system’s ability to perform the
required tasks reliably at a reasonable cost.
5. Design Models and Tools
• Abstract models, including diagrams and text, help manage cognitive processes and evaluate
design scenarios.
• Walk-throughs and scenario evaluations assist in identifying issues and refining solutions.
 6. Fitness for Purpose and Performance
• Systems should meet defined expectations of functionality and reliability.
• Context-specific considerations, like safety-critical systems, demand precise criteria, whereas
others (e.g., image recognition) may accept certain limitations.
• Designers must anticipate acceptable shortfalls and ensure they align with user expectations.
Characteristics of Good Design:
• Abstraction: Focus on core issues, discarding irrelevant details.
• Fitness for Purpose: The design must meet requirements effectively.
• Design Models: The outcome of the design process must be formally recorded and shared.
• Team Collaboration: Developers need a shared understanding of goals and models.
• Adaptability: Software designers often work across various domains, requiring diverse skills and
flexibility.

Software Design Principles

1. Fitness for Purpose

o The design must enable the system to perform its required tasks reliably without
unnecessary features.
o Avoid overcomplicating designs to reduce technical debt and maintain simplicity.
2. Separation of Concerns
o Each component of the design should handle a distinct task (e.g., user interaction, data
storage).
o Clear separation improves modularity, simplifies testing, and reduces technical debt
(avoids "spaghetti code").
3. Minimum Coupling
o Modules should have minimal dependencies to prevent ripple effects from changes.
o Dependencies should be limited to essential interactions, preserving modularity and
reducing technical debt.
4. Maximum Cohesion
o Elements within a module should serve a single purpose, focused on the module's core
function.
o Cohesion ensures logical grouping of functionalities, simplifying updates and
maintenance.
5. Information Hiding (Encapsulation)
o Keep internal data representation within a module hidden from others.
o Provide controlled access via methods to simplify future changes and maintain modular
integrity.

CLO_2 (Qian chapter 1-9)

The key components of an architecture style are:

• elements that perform functions required by a system
 • connectors that enable communication, coordination, and cooperation among
elements
• constraints that define how elements can be integrated to form the system
• attributes that describe the advantages and disadvantages of the chosen structure

Quality attributes can be categorized into the following three groups:

1. Implementation attributes (not observable at runtime)

• Interoperability: universal accessibility and the ability to exchange data among internal
components and with the outside world. Interoperability requires loose dependency of
infrastructure.
• Maintainability and extensibility: the ability to modify the system and conveniently
extend it.
• Testability: the degree to which the system facilitates the establishment of test cases.
Testability usually requires a complete set of documentation accompanied by system
design and implementation.
• Portability: the system's level of independence on software and hardware platforms.
Systems developed using high-level programming languages usualy have good
portability. One typical example is Java—most Java programs need only be compiled
once and can run everywhere.
• Scalability: a system's ability to adapt to an increase in user requests. Scalability
disfavors bottlenecks in system design.
• Flexibility: the ease of system modification to cater to different environments or
problems for which the system was not originally designed. Systems developed using
component-based architecture or service-oriented architecture usually possess this
attribute.
2. Runtime attributes (observable at runtime)
• Availability: a system's capability to be available 24/7. Availability can be achieved via
replication and careful design to cope with failures of hardware, software, or the
network.
• Security: a system's ability to cope with malicious attacks from outside or inside the
system. Security can be improved by insta ling firewall, establishing authentication and
authorization processes, and using encryption.
• Performance: increasing a system's efficiency with regard to response time,
throughput, and resource utilization, attributes which usually conflict with each other.
• Usability: the level of human satisfaction from using the system. Usability includes
matters of completeness, correctness, compatibility, a friendly user interface, complete
documentation, and technical support.
• Reliability: the failure frequency, the accuracy of output results, the Mean-Time-to-
Failure (MTTF), the ability to recover from failure, and the failure predictability.
• Maintainability (extensibility, adaptability, serviceability, testability, compatibility, and
configurability): the ease of software system change.
 3. Business attributes
• Time to market: the time it takes from requirements analysis to the date a product is
released.
• Cost: the expense of building, maintaining, and operating the system.
• Lifetime: the period of time that the product is “alive” before retirement.
Guidelines for developer
1. Abstract Design First
o Start with abstract designs that specify component interfaces and data types. These are
more stable and form the foundation for implementation decisions.
2. Consider Nonfunctional Requirements Early
o Map functional requirements to architecture designs while factoring in nonfunctional
attributes (e.g., performance, security). Balance quality attributes and consider various
architectural styles to meet them.
3. Focus on Reusability and Extensibility
o Design systems with future functionality expansion in mind. Consider reusing existing
components to enhance reliability and cost-effectiveness. Ensure the system is easily
extensible.
4. Promote High Cohesion and Loose Coupling
o Ensure subsystems, components, or modules are highly cohesive, performing a single
function. Maintain loose coupling to reduce interdependency between components,
minimizing ripple effects from changes.
5. Design Refinement is Necessary
o Understand that design is a continual process, and refinements will be needed. Use
prototyping and iterative methods to improve the design over time.
6. Avoid Ambiguity and Over-Detailing
o Avoid designs that are too vague (lacking constraints) or overly detailed (restricting
implementation). Aim for a balanced design that allows flexibility while providing clear
direction.

Role of a Software Architect

• Proposes architecture aligning with project requirements (functional and nonfunctional).

• Understands the design space and explores alternatives.
• Balances adaptability for evolving project needs and technological advancements.
Types of Software Structures
1. Software Static Structure
Describes code-level organization and interrelations:
• Elements: Source files, libraries (DLLs, JavaBeans), deployment descriptors, etc.
• Connectors Attributes:
o Direction: Unidirectional connections between modules.
o Synchronization: Synchronous or asynchronous method calls.
o Sequence: Ordered method invocations with sequence IDs.
 • Hierarchical Relations:
o Client-Server: Linear, non-transitive visibility.
o Refinement: Tree-like decomposition of components, often involving inheritance.
• Impact: Enhances clarity, maintainability, reusability, and system construction.
2. Software Runtime Structure
Focuses on execution-level elements and their interactions:
• Elements: Threads, processes, functional units, and data units.
• Connectors Attributes:
o Multiplicity: One element may connect to multiple runtime elements.
o Distance & Media: Varies from local to networked communication.
o Universally Invocable: Allows platform-agnostic interaction (e.g., heterogeneous
systems).
o Self-Descriptive: Enables dynamic interactions without pre-installed software.
3. Software Management Structure
Centers on team responsibilities and project stages:
• Elements: Specific code units managed by project teams.
• Connectors: Derived from runtime dependencies and team workflows.
• Purpose: Optimizes resource allocation and aligns teams with SDLC stages.

Software Elements

• Functions & Dependencies: Elements have well-defined functions and connect via connectors
forming a dependency graph.

• Transformation & Attributes: Refined through steps based on attributes and project
requirements.

• Synchronization & Performance:

o Reentrant Elements: Support multiple threads, improving efficiency and sharing

thread/process pools.

o Non-reentrant Elements: Require dedicated threads/processes for thread safety.

o Multiplicity:

▪ Limited: Invoked by specific elements.

▪ Unlimited: Invoked widely (e.g., servers) with constraints like scalability,

response time, and throughput.

Implementation Guidelines:

1. Reentrant Elements: Use threads or processes.

2. Non-reentrant Elements: Run on separate threads/processes for safety.

 3. High Multiplicity Elements: Use application servers for scalability (thread pooling, caching,
lifecycle management).

4. Heavy Computation: Deploy on processor clusters for load balancing and minimal
communication traffic.

5. Cost-Effective Implementation: Use off-the-shelf components if performance isn't critical.

6. Complex Elements:

o Expand into subsystems with encapsulated interfaces.

o Transform into vertical layers or horizontal tiers with clear interfaces.

Software Connectors

• Role: Facilitate communication between software elements.

• Refinement: Based on deployment environments (e.g., local method calls, message queues, or
remote invocations).

• Classification Attributes:

1. Synchronization Mode:

▪ Blocking: Waits for a response.

▪ Non-blocking: Continues execution without waiting.

2. Initiator:

▪ One-initiator: One-way requests.

▪ Two-initiator: Bidirectional requests.

3. Information Carrier:

▪ Local: Shared variables, pipes.

▪ Distributed: Remote method calls, messages.

4. Implementation Type:

▪ Signature-based: Fixed operation types.

▪ Protocol-based: Flexible operations via messages (e.g., HTTP).

5. Active Time:

▪ Programmed: Triggered by code.

 ▪ Event-driven: Reactive to events.

6. Span:

▪ Local: Same processor.

▪ Networked: Different processors (uses proxy patterns for abstraction).

7. Fan-out:

▪ 1-1: Between two elements.

▪ 1-*: One-to-many connections (e.g., client-server).

8. Environment:

▪ Homogeneous: Same platform/language.

▪ Heterogeneous: Different platforms/languages (uses broker patterns with data

marshaling/unmarshaling).

Design Patterns for Connectors

1. Proxy Pattern: Abstracts networked connectors, enabling seamless interaction.

2. Broker Pattern: Supports heterogeneous systems by converting data to platform-independent

formats.

Architecture Description Language (ADL)

Garlan and Shaw (1996) list the following requirements for an ADL:

• Composition: “It should be possible to describe a system as a composition of independent

components and connections.” Large systems should be built from constituent elements, and it
should be possible to consider each element independently of the system.

• Abstraction: “It should be possible to describe the components and their interactions in a way
that describes their abstract roles in a system.” It should not be necessary to consider
implementation issues while specifying the architecture.

• Reuse: Reusability should be built-in at the component and connection level. The derivation of
architecture patterns should also be supported to facilitate the reuse of architecture
descriptions.

• Configuration: Architecture descriptions should enable comprehension and modification of an

architecture without examination of each component and connector.
 • Heterogeneity: “It should be possible to combine multiple, heterogeneous architectural
descriptions.”

• Analysis: The use of an ADL should facilitate the analysis of an architecture design. Analysis
might include consideration of throughput, deadlock, input/output behavior, and scheduling.

Design Principles for OO Analysis and Design

1. Principle of Decoupling:

• Concept: Minimize interdependence among classes to ease maintenance.

• Benefits:

o Reduced interdependency.

o Easier system extension.

o Simplified implementation.

2. Ensuring Cohesion:

• Concept: A class should perform closely related operations.

• Benefits:

o Simplifies system management.

o Easier maintenance and expansion.

3. Open-Closed Principle:

• Concept: A system should be open to extension but closed to modification.

• Guidelines:

o Separate interface and implementation.

o Keep attributes private to avoid ripple effects and ensure thread safety.

o Minimize the use of global and static variables to prevent misuse and crashes.

Data Flow Architecture

1. Batch Sequential
Applicable domains of batch sequential architecture:
• Data are batched. • Intermediate file is a sequential access file.
• Each subsystem reads related input files and writes output files.
 Benefits:
• Simple divisions on subsystems.
• Each subsystem can be a stand-alone program working on input data and producing output data.
Limitations:
• Implementation requires external control. • It does not provide interactive interface.
• Concurrency is not supported and hence throughput remains low • High latency
2. Pipe and Filter Architecture
Applicable domains of pipe and filter architecture:
• The system can be broken into a series of processing steps over data streams, and at each step filters
consume and move data incrementally.
• The data format on the data streams is simple, stable, and adaptable if necessary.
• Significant work can be pipelined to gain increased performance.
• Producer or consumer-related problems are being addressed.
Benefits:
• Concurrency: It provides high overal throughput for excessive data processing.
• Reusability: Encapsulation of filters makes it easy to plug and play, and to substitute.
• Modifiability: It features low coupling between filters, less impact from adding new filters, and
modifying the implementation of any existing filters as long as the I/O interfaces are unchanged.
• Simplicity: It offers clear division between any two filters connected by a pipe.
• Flexibility: It supports both sequential and para lel execution.
Limitations:
• It is not suitable for dynamic interactions.
• A low common denominator is required for data transmission in the ASCI formats since filters may
need to handle data streams in different formats, such as record type or XML type rather than character
type.
• Overhead of data transformation among filters such as parsing is repeated in two consecutive filters.
• It can be difficult to configure a pipe and filter system dynamicaly.
3. Process Control Architecture
Applicable domains of process control architecture:
• Embedded software systems involving continuing actions
• Systems that need to maintain an output data at a stable level
• The system can have a set point—the goal the system wil reach at its operational level.
Benefits:
• It offers a better solution to the control system where no precise formula can be used to decide the
manipulated variable.
• The software can be completely embedded in the devices
Data centered Architecture
1. Repository Architecture Style
Benefits:
• Data integrity: easy to back up and restore
• System scalability and reusability of agents: easy to add new software components because they do
not have direct communication with each other
 • Reduces the overhead of transient data between software components
Limitations:
• Data store reliability and availability are important issues. Centralized repository is vulnerable to failure
compared to distributed repository with data replication.
• High dependency between data structure of data store and its agents. Changes in data structure have
significant impacts on its agents. Data evolution is more difficult and expensive. • Cost of moving data on
network if data is distributed.
2. Blackboard Architecture Style
Benefits:
• Scalability: easy to add or update knowledge source.
• Concurrency: al knowledge sources can work in paralel since they are independent of each other.
• Supports experimentation for hypotheses.
• Reusability of knowledge source agents.
Limitations:
• Due to the close dependency between the blackboard and knowledge source, the structure change of
the blackboard may have a significant impact on a l of its agents.
• Since only partial or approximate solutions are expected, it can be difficult to decide when to terminate
reasoning.
• Synchronization of multiple agents is an issue. Since multiple agents are working and updating the
shared data in the blackboard simultaneously, the preference or priority of executions of multiple agents
must be coordinated.
• Debugging and testing of the system is a challenge
Hierarchical Architecture
1. Main-Subroutine
Benefits:
• It is easy to decompose the system based on the definition of the tasks in a top-down refinement
manner.
• This architecture can still be used in a subsystem of OO design.
Limitations:
• Globally shared data in classical main-subroutines introduces vulnerabilities.
• Tight coupling may cause more ripple effects of changes as compared to OO design.
2. Layered
Benefits:
• Incremental software development based on increasing levels of abstraction.
• Enhanced independence of upper layer to lower layer since there is no impact from the changes of
lower layer services as long as their interfaces remain unchanged.
• Enhanced flexibility
• Component-based technology is a suitable technology to implement layered architecture; this makes
it much easier for the system to alow for plug-and-play of new components.
• Promotion of portability: each layer can be an abstract machine (see Section 7.5 ) deployed
independently.
Limitations:
• Lower runtime performance since a client's request or a response to a client must go through
potentially several layers.
• Many applications cannot fit this architecture design.
• Breach of interlayer communication may cause deadlocks, and “bridging” may cause tight coupling.
• Exceptions and error handling are issues in the layered architecture
3. Virtual Machine
Benefits:
• Portability and machine platform independency
• Simplicity of software development
• Simulation for disaster working model
Limitations:
• Slow execution of the interpreter due to interpreter nature
• Additional overhead due to the new layer.
Implicit Asynchronous Communication Software Architecture
1. Nonbuffered Event-Based Implicit Invocations
Benefits:
• Framework availability: Many vendor APIs such as Java AWT and Swing components are available.
• Reusability of components: It is easy to plug in new event handlers without affecting the rest of the
system.
• System maintenance and evolution: Both event sources and targets are easy to update.
• Independency and flexible connectivity: Dynamic registration and deregistration can be done
dynamically at runtime.
• Parallel execution of event handling is possible.
Limitations:
• It is difficult to test and debug the system since it is hard to predict and verify responses and the order
of responses from the listeners.
• tighter coupling between event sources and their listeners
• Reliability and overhead of indirect invocations may be an issue.
2. Buffered Message-Based Software Architecture
Benefits:
• Anonymity: provides high degree of anonymity between message producer and consumer.
• Concurrency: supports concurrency both among consumers and between producer and consumers.
• Scalability and reliability of message delivery: Reliability mechanisms include: control level setting of
message acknowledgement; message persistence setting without loss; message priority level setting;
and message expiration setting.
• Supports batch processing.
• Supports loose coupling between message producers and consumers, and between legacy systems and
modern systems for integration development.
Limitations:
• Capacity limit of message queue: This is not an inherent limitation but an implementation issue that
can be minimized if the queue is implemented as a dynamic data structure (e.g., linked lists). However,
there is an absolute limit based on available memory. It is also difficult to determine the numbers of
agents needed to satisfy the loose couplings between agents.
• Complete separation of presentation and abstraction by control in each agent generates development
complexity since communication between agents only takes place between the control of agents.
• Increased complexity of the system design and implementation
Interaction-Oriented Software Architecture
1. Model-View-Controller (MVC)
Benefits:
• Many MVC vendor framework toolkits are available.
• Multiple views synchronized with same data model.
• Easy to change or plug in new interface views, allowing updating of interface views with new
technologies without overhauling the rest of the system.
• Very effective for developments if graphics, programming, and database development professionals
are working in a team in a designed project.
Limitations:
• Not suitable for agent-oriented applications such as interactive mobile and robotics applications.
• Multiple pairs of controlers and views based on the same data model make any data model change
expensive.
• The division between the View and the Controler is not clear in some cases.
2. Presentation-Abstraction-Control (PAC)
Benefits :
• Support of multitasking and multiviewing
• Support agent reusability and extensibility
• Easy to plug in new agent or replace an existing one
• Support for concurrency where multiple agents run in paralel in different threads or on different
devices or computers
Limitations:
• Extra time lost.
• Difficult to determine the correct number of the agents due to the loose coupling and high
independence between agents.
• Complete separation of presentation and abstraction by control in each agent generates development
complexity since communications between agents only take place between the controls of agents.

Distributed Architecture
1. Client-Server
Advantages:
• Separation of responsibilities such as user interface presentation and business logic processing
• Reusability of server components
Disadvantages:
• Lack of heterogeneous infrastructure to deal with the requirement changes
• Security complications
• Server availability and reliability
• Testability and scalability
• Fat clients with presentation and business logic together
2. Broker architecture style
Definition: The Broker Architecture is a middleware pattern facilitating communication between clients
and servers through a broker component, ensuring decoupled interaction via remote service invocations.
Key Components:
1. Broker:
o Manages communication by forwarding requests, locating servers, and returning results
or exceptions.
o Stores server registration information and provides APIs for client-server interactions.
2. Stub (Client Proxy):
o Mediates between the client and broker, offering transparency.
o Handles protocol-level communication, marshaling arguments, and unmarshaling
results.
3. Skeleton (Server Proxy):
o Mediates between the server and broker, managing system-specific networking.
o Unpacks requests, invokes services, and marshals results for the client.
4. Bridges (Optional):
o Enable interoperability between different brokers (e.g., DCOM, CORBA).
o Translate requests and parameters between formats.
5. Network:
o Connects components using protocols like TCP/IP, SOAP, or HTTP for data transfer.
Workflow:
• Client requests are intercepted by the client-proxy, processed by the broker, and forwarded to
the server-proxy.
• The server-proxy invokes the appropriate service and returns results to the broker, which
forwards them to the client.
Advantages:
• Transparency in server implementation and location.
• Flexibility for runtime changes (e.g., adding/removing servers).
• Simplified client access and server portability.
• Enhanced reusability and interoperability via bridges.
Disadvantages:
• Overhead from proxies reduces efficiency.
• Low fault-tolerance.
• Complex testing due to multiple proxies.
Applications:
• Commonly implemented in systems like CORBA, Java RMI, and .NET Remote, enabling seamless
distributed service access with location transparency and minimal client effort.
Message broker architecture
Advantages:
• Reusability and maintainability: Loose coupling between the client and server component leads to easy
maintenance and extension on both sides.
• Flexibility: Invocation-oriented or document-oriented messaging; message heading and body can be
altered for specific purposes.
Disadvantages:
• Overhead, indirection complexity, and difficulty in debugging and testing due to the new protocol stack
added
3. Service-Oriented Architecture (SOA)
Definition:
Service-Oriented Architecture (SOA) is a design paradigm where business processes are implemented as
modular, reusable, and independent services with well-defined interfaces. These services communicate
using universal protocols like SOAP, XML, and HTTP, ensuring loose coupling and platform independence.
SOA enables the reuse of services across applications and simplifies the integration of legacy systems.
How It Works:
• Clients access services via a service directory.
• Services interact through message-oriented protocols.
• Business workflows are orchestrated using languages like BPEL, enabling seamless integration of
services.
Key Features:
• Loose Coupling: Services are stateless and independent, allowing for seamless updates without
impacting clients.
• Service Composition: Complex applications can be built by aggregating and reusing atomic
services.
• Interoperability: Services communicate regardless of platform, technology, or language.
Advantages of SOA:
1. Loosely-Coupled Connections:
o Independent service components ensure easier evolution and updates.
o Stateless design enables scalability and flexibility.
2. Interoperability:
o Allows seamless communication across platforms, technologies, and vendors.
o Universal message formats like XML enhance compatibility.
3. Reusability:
o Services can be reused across applications, reducing development time and costs.
o Promotes efficiency and consistency in business applications.
4. Scalability:
o Easily scales to accommodate growing business demands.
o Coarse-grained and asynchronous design improves performance under load.
SOA in Practice:
• Web Services: Implemented using protocols like SOAP and WSDL for communication and
description.
• BPEL: Orchestrates workflows among services, defining their sequence and interactions.
 • Grid Service Computing: Leverages SOA to integrate distributed computational and data
resources for efficient resource management.
Component-Based Software Architecture
Applicable domains of component-based architecture:
• Applications where the interface contracts between subsystems are clear
• Applications that require loose coupling between the components and where many reusable
components are available
• Suitable for the class library system organization (.NET class library and Java API are built in component
architecture)
Benefits:
• Reusability of components.
• System maintenance and evolution; easy to change and update the implementation without affecting
the rest of the system.
• Independency and flexible connectivity of components.
• Independent development of components by different groups in parallel.
• Productivity for the current and future software development.
• Many OO design tools can also be used for component-based software development.
Limitations:
• It can be difficult to find suitable available components to reuse.
• Adaptation of components is an issue.
• Few component-oriented dedicated design tools are available
CLO-3 (Gorton Chapter 4)

Classification of middleware technologies

1. The transport layer provides basic pipes for sending requests and moving data, ensuring
straightforward data exchange in distributed architectures.
2. Application servers, built on transport services, offer transaction, security, and directory services
while supporting a programming model for creating multithreaded, server-based applications.
3. Message brokers utilize a basic transport service and/or application servers, incorporating a
specialized message processing engine that offers fast message transformation and high-level
programming features for routing, manipulating, and exchanging messages between application
components.
4. Business process orchestrators (BPOs) augment message broker features to support workflow-
style applications. In such applications, business processes may take many hours or days to
complete due to the need for people to perform certain tasks. BPOs provide the tools to
describe such business processes, execute them and manage the intermediate states while each
step in the process is executed.

Design concerns addressed in application:

 • Requests to servants are remote calls, and hence relatively expensive (slow) as they traverse
the ORB and network. This has a performance impact. It’s always wise to design interfaces so
that remote calls can be minimized, and performance is enhanced.
• Like any distributed application, servers may intermittently or permanently be unavailable
due to network or process or machine failure. Applications need strategies to cope with
failure and mechanisms to restart failed servers.
• If a servant holds state concerning an interaction with a client (e.g., a customer object stores
the name/address), and the servant fails, the state is lost. Mechanisms for state recovery
must consequently be designed.

Message-Oriented Middleware

MOM uses in applications:

• Scenario when the sender

doesn’t need a reply to a
message. This is known as send
and-forget messaging.
• The sender doesn’t need an immediate reply to a request message. The receiver may
take perhaps several minutes to process a request, and the sender can be doing useful
work in the meantime rather than just waiting.
• The receiver, or the network connection between the sender and receiver, may not
operate continuously. The sender relies on the MOM to deliver the message when a
connection is next established. The MOM layer must be capable of storing messages for
later delivery, and possibly recovering unsent messages after system failures.

MoM advanced features:

1. Message delivery

Quality of service:

Best effort: The MOM server will do its best to deliver

the message. Undelivered messages are only kept in memory on the server and can be lost if a
system fails before a message is delivered.

Persistent: The MOM layer guarantees to deliver messages despite system and network failures.
Undelivered messages are logged to disk as well as being kept in memory and so can be recovered
and subsequently delivered after a system failure.

Transactional: Messages can be bunched into “all or nothing” units for delivery.

2. Transactions:
 Transactional messaging makes sure that messages are sent or received only when a related task
(like a database update) is successfully completed. If the task is canceled, the message is not
sent, keeping everything consistent and reliable.
3. Clustering:
MOM server clustering improves reliability and
scalability. If one server fails, others handle the
queues, ensuring continuous communication. It
also balances the workload across servers,
distributing client requests to prevent any single
server from being overloaded.

4. Two-way messaging:
Although MOM is typically asynchronous, it can also support synchronous communication. In
this case, the sender sends a request message to the receiver and waits for a reply on a specified
reply queue. This approach is often used in enterprise systems because it integrates easily with
existing applications, works across various platforms (including legacy systems), and leverages
existing investments in messaging technology without requiring complex changes.
Publish subscribe:
Publish–subscribe messaging extends MOM to support communication between multiple
publishers and subscribers using topics. Publishers send messages to a topic, and all active
subscribers listening to that topic receive the message. Multicast-based systems, like TIBCO’s
Rendezvous, send a single copy of the message over the network, improving performance and
scalability compared to point-to-point solutions, especially in high-throughput scenarios.
Topics:
Hierarchical topic naming in publish–subscribe systems uses structured strings with “/”
separators and supports wildcards like * and ** for flexible subscriptions. This allows subscribers
to receive messages from multiple topics or entire branches dynamically without changing their
subscription as new topics are added.
5. Application Server:
Following are the tiers of application server
1. Client Tier: In a web application, the client tier typically comprises an Internet browser that
submits HTTP requests and downloads HTML pages from a web server.
2. Web Tier: The web tier runs a web server to handle client requests. When a request arrives,
the web server invokes web server-hosted components such as servlets, Java Server Pages
(JSPs) or Active Server Pages (ASPs) depending on the flavor of web server being used.
3. Business Component Tier: The business components comprise the core business logic for the
application. The business components are realized by for example Enterprise JavaBeans (EJB)
in JEE, .NET components or CORBA objects.
4. Enterprise Information Systems Tier: This typically consists of one or more databases and
back-end applications like mainframes and other legacy systems.

EJB Container Responsibilities

• Lifecycle Management: Manages creation, activation, passivation, and destruction of beans.

• Interception: Enforces transaction and security constraints on client calls.

• Session Bean Behavior: Manages state and behavior of session beans.

• Threading and Caching: Allocates threads and maintains caches of entity beans.

• Connection Pooling: Manages a pool of database connections for efficient resource access.

Chapter 5

Service-Oriented Architectures and Technologies

1. Service-Oriented Systems
The shift to service-oriented systems is driven by the need for better integration of
applications and business systems, moving away from traditional paper-based methods to
electronic communication via the Internet and Web services.
Basic principles:
1. Boundaries Are Explicit
The first tenet emphasizes that services are independent applications requiring careful
design to manage boundaries that can affect performance and complexity. To address
these challenges, services should be designed with simplicity in mind, featuring
straightforward interfaces and minimal shared assumptions to enhance usability for
remote developers.
2. Services Are Autonomous
a. Services are independent applications, not tightly bound components.

b. Must handle incoming requests correctly formatted and meeting security

requirements.

c. Service owners can change implementations without affecting clients, as long as

messages remain compatible.

3. Share Schemas and Contracts, Not Implementations

a. Services are applications that send and receive messages, sharing only message
definitions (schemas) and contracts.

b. Clients use contracts to build request messages; services validate incoming

messages against schemas.

4. Service Compatibility Is Based on Policy

a. Compatibility includes following message formats and other requirements like
encryption and tracking.
 b. Policies define nonfunctional requirements and can be used dynamically at run-
time.

c. Policies help generate compatible code and enable client applications to adapt
to different service providers.

Web Services:

• Web services are integration technologies designed to address the needs of service-oriented
architectures (SOA).
• They focus on simplicity, interoperability, and standardization across various software vendors.

Core Functions of Web Services:

• Find Suitable Services: Using directories like UDDI.

• Discover Service Details: Using WSDL (Web Services
Description Language).
• Service Invocation: Using SOAP (Simple Object Access
Protocol).
• Security and Other Services: Utilizing WS- standards (e.g., WS-Security).

How webserver provide security?

Soap and Messaging

• A simple, extensible XML-based communication protocol for remote service invocation.

• Simplicity: Avoids complex issues like distributed garbage collection and object references,
making it easier to implement.

UDDI, WSDL, and Metadata

1. Metadata and Policy in Web Services:

• Web services use metadata to describe and discover services and define policies for
things like security and reliability.
• WS-Policy and WS-Security Policy are used to specify security and reliability
requirements for services.

2. UDDI (Universal Description, Discovery, and Integration):

• Purpose: UDDI provides a directory for discovering and integrating services.

• Usage: UDDI has not been widely adopted, with many organizations relying on personal
contacts or lists for service discovery.
• Future Potential: Industry associations may drive the adoption of UDDI as they release
service definitions and publish service provider directories.

3. WSDL (Web Services Description Language):

• Purpose: WSDL is used to describe Web services, including their operations, parameters,
and interfaces.
• Structure: WSDL documents describe services, such as the StockQuoteService, and
include information about messages, operations, and bindings.
• Example: The StockQuoteService offers the operation GetLastTradePrice, which takes a
stock symbol as input and returns the last traded price as a float.

WSDL Example:

• Operation: GetLastTradePrice
• Input: Stock symbol (string)
• Output: Last traded price (float)
• Tool Support: Tools like Visual Studio, Eclipse, and WebSphere automatically generate
WSDL from method definitions and make it easier for developers to integrate services.

4. Challenges with WSDL:

• While WSDL is useful for defining services, it may encourage developers to treat services
as remote methods, rather than embracing the richer, message-based interaction model
that Web services provide.

Security, Transactions, and Reliability

Middleware protocols often face connectivity issues on the open Internet due to firewall
restrictions, leading Web services to use HTTP as a transport layer. WS-Security addresses
resulting security concerns with cryptographic mechanisms for authentication, encryption,
and integrity, while WS-ReliableMessaging and transaction standards like WS-
AtomicTransactions and WS-BusinessActivity ensure reliable communication and
coordinated application integration.

RESTful Web Services

SOAP-based Web services use HTTP as an optional transport layer but lack adherence to
Web principles, leading to the rise of RESTful Web services, which fully leverage HTTP
methods (GET, POST, PUT, DELETE) and standard Web technologies for resource
representation via URIs. While REST is simpler and suitable for straightforward use cases,
SOAP and WS-standards are better suited for complex applications requiring robust
security, reliability, and interoperability. Both approaches are complementary, catering to
different architectural needs.

Chapter 6

Advanced Middleware Technologies

Message Brokers

1. Introduction to Message Brokers:When integrating legacy systems with differing data

formats, message brokers offer a solution by facilitating communication and ensuring
consistent data formats across systems.

2. Motivating Example:

• Legacy Systems: Consider an organization with four legacy business systems, each
storing customer information in different formats. To update customer data, the
organization decides to create a web component that passes updated customer data to
each system using MOM.

3. Message Transformation:

• Each legacy system has an interface component that reads messages, transforms the
data into the system’s specific format, and invokes the system's API to update customer
records.
• Tight Coupling: The systems must agree on a message format, which creates tight
coupling. Any changes in the message format require updates across multiple
components, making it complex to manage.

4. Solution with Message Brokers:

• Message Broker Approach: A message broker decouples the systems by taking over the
responsibility of message format transformation. The web component sends the data in
the common format to the broker, which then transforms the data into the appropriate
format for each legacy system.
• Benefits:
o Reduces the complexity in the web and legacy components, as the
transformation logic is centralized within the broker.
o Changes to the message format only require modifications in the broker
 5. Advanced Features of Message Brokers:

• Complex Transformations: Brokers can handle complex data transformations, such as

string formatting, data conversion, and mathematical operations.
• High Performance: Message brokers often provide high-performance, multithreaded
engines to handle multiple transformation requests simultaneously.
• Message Routing: Brokers can route messages based on specific data values. They also
support exception handling, ensuring that invalid messages are appropriately processed.

7. Benefits of Using Message Brokers:

• Centralized Integration Logic: The integration logic is managed centrally, making it

easier to update and maintain.
• Performance: Brokers are optimized for high-speed transformations, often handling
messages in milliseconds.
• Reliability: In case of a failure, message brokers can reprocess failed transformations,
ensuring reliability.

8. Challenges and Drawbacks:

• Vendor Lock-in: Many message broker products are

proprietary, leading to potential vendor lock-in.
• Performance Bottlenecks: In high-volume applications,
the broker itself can become a bottleneck, though
clustering can address scalability and reliability concerns.
• Complexity and Cost: Broker clustering and advanced
features often introduce additional complexity and cost.

Mule: An example of a high-quality open-source message

broker that offers a viable alternative to proprietary
solutions in many integration scenarios.

Business Process Orchestration

Business processes in modern enterprises often involve complex interactions between multiple
systems, requiring seamless integration and reliable transaction management.

Key Features of BPO Platforms:

1. State Management: The state of a business process is stored persistently, allowing it to recover
from failures without losing progress. This state is only reactivated when needed, thus
optimizing computational resources.

2. Development and Deployment Tools: BPO platforms typically

come with tools for defining processes visually, deploying them
across different systems, and connecting with message queues,
web services (SOAP), and file systems.

Compensating Transactions: If a business process fails, the BPO

platform triggers compensating transactions to reverse any partial
updates made to the systems.

Integration Architecture Issues

Integrating disparate enterprise applications faces challenges of modifiability, as evolving

business processes create complex system dependencies.

Point-to-Point Architecture and Its Limitations

1. Incremental Integration Complexity

o Initial integration of five applications results in multiple interfaces, where each
system must transform its data to meet the formats of others.
o For example, one business process with four interfaces expands to 20 interfaces
across five processes, creating exponential growth in dependencies.
2. Scalability Issues
o In general, the number of interfaces in a point-to-point system is proportional to
N2−NN^2 - NN2−N, making it non-scalable as the number of applications
increases.
o These architectures, often referred to as spaghetti architectures, become
difficult and risky to modify due to interdependent systems.

The Role of Message Brokers

1. Simplifying Complexity
o A message broker centralizes transformations, allowing applications to send
messages in their native formats while converting them to target formats
internally.
o This reduces tight coupling between applications and simplifies endpoint
changes.
2. Drawbacks of Message Brokers
o Hidden Complexity: The spaghetti architecture still exists within the broker, with
intricate dependencies captured in its transformations.
 o Performance Bottlenecks: Brokers can slow down communication and require
complex, costly setups for scaling, such as clustering and replication.

The Canonical Data Model as a Solution

To address these limitations, an enterprise data model (canonical data model) serves as a
shared format for all message transformations. Applications transform their data to this
standard format, enabling scalable and modifiable integration without relying entirely on
message brokers. For example, a canonical customer data format can standardize
transformations across all business systems.

How Does a Canonical Message Format Facilitate Data Exchange?

1. Source application transforms local customer data into canonical customer information
format.
2. Source sends message to target with canonical message format as payload.
3. Target receives message and transforms the canonical format into its own local
customer data representation. This means that each end point (business application)
must know
4. How to transform all messages it receives from the canonical format to its local format
5. How to transform all messages it sends from its local format to the canonical format

However, the use of a canonical data model has some challenges:

1. Designing the model: Creating a common data model for all systems can be difficult, especially
in an organization with diverse, legacy systems.

2. Industry standards: In some cases, external systems or business partners may use incompatible
formats, making it impossible to establish a single canonical format across the entire supply
chain. In such cases, industry standards like RosettaNet or ebXML can be useful for defining
common formats.

3. Incremental adoption: Large organizations rarely have the luxury of designing their enterprise
data model upfront. It is often adopted incrementally, which can delay its full benefits.

What Is an Enterprise Service Bus

1. Introduction to ESB

o The term ESB stands for Enterprise Service Bus.

o Initially, the term may have confused some, as it doesn’t refer to anything related to
software integration but is an acronym for integration middleware technology.
 2. General Definition

o An ESB is typically seen as middleware that enables complex integration architectures

through:

▪ Event-driven mechanisms.

▪ Standards-based messaging engines.

o The core functionality of an ESB includes supporting communication between system

endpoints via a variety of protocols like TCP/IP, SOAP, JMS, and FTP.

3. Core Features of ESBs

o ESBs are responsible for connecting various system endpoints using different protocols.

o They typically serve as a messaging hub to facilitate communication and data exchange
in enterprise-level applications.

4. Conclusion

o An ESB is designed to simplify and standardize the integration of services and

applications in a Service-Oriented Architecture (SOA).

o It provides fundamental capabilities for integrating systems, reducing complexity in

large-scale enterprise integrations.

Chapter 7

A Software Architecture Process

1. Role of an architect
• Work with the requirements team: The requirements team elicits functional
requirements, while the architect ensures system needs and quality attributes are clearly
defined and understood.
• Work with various application stakeholders: Architects ensure stakeholder needs,
including business and technical requirements, are understood and integrated into the
application design.
• Lead the technical design team: The architect leads a design team, comprising system
designers (or on large projects, other architects) and technical leads to produce the
architecture blueprint.
• Work with the project management: The architect works closely with project
management, helping with project planning.
2. Steps of Architecture Design process
1. Determine Architectural Requirements: This involves creating a statement or model of the
requirements that will drive the architecture design.
2. Identifying Architecture Requirements

3. Prioritizing Architecture Requirements

1. High: the application must support this requirement.

These requirements drive the architecture design.

2. Medium: this requirement will need to be supported at some stage, but not necessarily in the
first/next release.

3. Low: this is part of the requirements wish list. Solutions that can accommodate these
requirements are desired, but they are not the drivers of the design.

Prioritization gets trickier in the face of conflicting requirements. Common examples are:
Reusability of components in the solution versus rapid time-to-market. Making components
generalized and reusable always takes more time and effort.

Minimal expenditure on COTS products versus reduced development effort/ cost. COTS products
mean you must develop less code, but they cost money.
 2.

3. Architecture Design

The architecture design process involves iteratively selecting proven patterns and defining components
within a framework, resulting in architecture views and a design document detailing decisions, rationale,
and risks, relying heavily on experience.

• Choosing the Architecture Framework: Most applications leverage proven architectures to

reduce risk and ensure reliability. The design process starts with selecting a suitable framework,
from simple patterns like n-tier client-server for small apps to integrated patterns for complex
systems, requiring an understanding of how patterns address quality attributes.
• N-Tier Client Server:

Properties:

1. Separation of concerns: Presentation, business and data handling logic are clearly
partitioned in different tiers.
2. Synchronous communications: Each tier waits for a response from the other tier before
proceeding.
3. Flexible deployment: There are no restrictions on how a multi-tier application is deployed.

Quality Attributes:

1. Availability: Servers in each tier can be replicated, so that if one fails, others remain
available. Overall, the application will provide a lower quality of service until the failed
server is restored.
2. Failure handling: If a client is communicating with a server that fails, most web and
application servers implement transparent failover, redirecting the client request to a live
replica server without its knowledge.
3. Modifiability: Separation of concerns improves modifiability by isolating presentation,
business, and data logic, allowing changes within one tier without affecting others.
4. Performance: This architecture is fast, but it’s important to consider server capacity,
connection speed, data size, and reducing the number of calls between tiers.
 5. Scalability: As servers in each tier can be replicated, and multiple server instances run on the
same or different servers, the architecture scales out and up well.
• Messaging:
Properties:
1. Asynchronous communications: Clients send requests to the queue, where the message is
stored until an application removes it.
2. Configurable QoS: The queue can be configured for high-speed, nonreliable or slower,
reliable delivery.
3. Loose coupling: There is no direct binding between clients and servers.
• Quality attributes:
1. Availability: Physical queues with the same logical name can be replicated across different
messaging server instances. When one fails, clients can send messages to replica queues.
2. Failure handling: If a client is communicating with a queue that fails, it can find a replica
queue and post the message there.
3. Modifiability: Messaging is inherently loosely coupled, and this promotes high modifiability
as clients and servers are not directly bound through an interface. Self-describing,
discoverable message formats can help reduce this dependency on message formats.
4. Performance: Message queuing technology can deliver thousands of messages per second.
5. Scalability: Queues can be hosted on the communicating endpoints or be replicated across
clusters of messaging servers hosted on a single or multiple server machines. This makes
messaging a highly scalable solution.

Publish–Subscribe:

• Properties:
1. Many-to-Many messaging: Published messages are sent to all subscribers who are registered
with the topic.
2. Configurable QoS: Communication can be point-to-point, sending separate messages to each
subscriber, or broadcast/multicast, sending one message to all subscribers.
3. Loose Coupling: As with messaging, there is no direct binding between publishers and
subscribers. Publishers do not know who receives their message, and subscribers do not
know which publisher sent the message.
• Quality attributes:
1. Availability: Topics with the same name can be replicated across server clusters, so if one fails,
publishers send messages to replica queues.
2. Failure handling If a publisher is communicating with a topic hosted by a server that fails, it can
find a live replica server and send the message there
3. Modifiability: Publish–subscribe is inherently loosely coupled, and this promotes high
modifiability. New publishers and subscribers can be added to the system without changing the
architecture or configuration.
4. Performance Publish–subscribe can deliver thousands of messages per second, with nonreliable
messaging faster than reliable.
5. Scalability: Topics can be replicated across clusters of servers hosted on a single or multiple
server machines.

Broker:

Properties:

1. Hub-and-spoke architecture: The broker acts as a messaging hub, and senders and receivers
connect as spokes. Connections to the broker are via ports that are associated with a specific
message format.
2. Performs message routing: The broker embeds processing logic to deliver a message received on
an input port to an output port. The delivery path can be hard coded or depend on values in the
input message.
3. Performs message transformation: The broker logic transforms the source message type
received on the input port to the destination message type required on the output port.

Quality Attributes:

1. Availability: To ensure high availability, brokers must be replicated, often using similar
mechanisms to messaging and publish-subscribe server clustering.
2. Failure handling: Brokers validate messages through typed input ports, discarding incorrect
formats, and with replicated brokers, senders can switch to a live broker if one replica fails.
3. Modifiability: Brokers isolate transformation and routing logic from senders and receivers,
improving modifiability by allowing changes without impacting them.
4. Performance: Brokers can potentially become a bottleneck, especially if they must service
high message volumes and execute complex transformation logic.
5. Scalability: Clustering broker instances makes it possible to construct systems scale to handle
high request loads.

Process Coordinator:

Properties:

1. Process encapsulation: The process coordinator defines and manages the sequence of steps
in a business process, making it easier to understand and modify by initiating the process,
calling servers in order, and emitting results.
2. Loose coupling: Server components are unaware of their role or the process order; they
simply provide services that the coordinator calls as needed in the business process.
3. Flexible communications: Communications between the coordinator and servers can be
synchronous or asynchronous. For synchronous communications, the coordinator waits until
the server responds. For asynchronous communications, the coordinator provides a callback
or reply queue/topic and waits until the server responds using the defined mechanism.

Quality Attributes:
 4. Component Allocation in Architecture Design

Once an overall architecture framework is selected, the next task is to define the major
components that make up the design. The framework sets the communication patterns between
components, and additional considerations must include:

Key Tasks in Defining Components:

• Identify Major Components: Define the major application components and how they fit into the
framework.

• Define Interfaces and Services: Specify the services each component supports.

• State Component Responsibilities: Clarify what each component will do when receiving a
request.

• Identify Component Dependencies: Determine the relationships between components.

• Consider Distribution: Identify which components are suitable for distribution across multiple
servers.

Guidelines for Component Design:

• Minimize Dependencies: Strive for loosely coupled components, so changes to one component
do not affect others.

• Design for Cohesion: Components should have a small, well-defined set of responsibilities,
minimizing maintenance and testing efforts.
• Isolate Dependencies: Reduce the number of components relying on middleware or COTS
technologies, making upgrades easier.

• Use Hierarchical Decomposition: Structure components in layers, with higher-level components

delegating calls to internal components.

• Minimize Inter-Component Calls: Reduce costly communication between distributed

components by aggregating calls into single requests.

5. Validation:
Architecture Validation
The goal of the validation phase is to ensure the architecture is fit for its intended purpose.
Since a design can't be directly executed or tested, validation is crucial to identify potential
flaws before implementation.
Validation Techniques:
1. Manual Testing: Test scenarios are used to assess the architecture manually.
2. Prototyping: A prototype is built to simulate a simplified version of the application and test its
ability to meet requirements.

7.3.1 Using Scenarios

Scenarios are used to evaluate an architecture's response to specific stimuli, helping identify
potential flaws or areas of risk. They focus on key architectural concerns such as quality
attributes and assess how the architecture handles specific events.
Scenario Examples:
 7.3.2 Prototyping
Prototypes are used to address high-risk areas in a design by testing aspects that are difficult
to validate through design alone. They serve two main purposes:
1. Proof-of-concept: Verifies if the architecture can meet requirements.
2. Proof-of-technology: Tests the behavior of selected technologies (middleware, libraries, etc.).
Prototyping Example:
For the order processing system scenario, a prototype could test if 5,000 orders can be
processed in 5 minutes. Components like the queue and email systems, which are known to
perform well, wouldn’t need to be included in the prototype. Instead, the prototype would
focus on testing the Customer and Order system APIs for performance under load.
Caution on Prototyping:
Prototypes should be developed quickly (in a few days to a couple of weeks) and discarded
once their purpose is fulfilled. They are meant to reduce risks and validate specific design
concerns but should not evolve into full-fledged projects.

Chapter 8

Documenting a Software Architecture

Documenting architectures is problematic though, because:

• There’s no universally accepted architecture documentation standard.

• An architecture can be complex and documenting it in a comprehensible manner is time
consuming and nontrivial.
• An architecture has many possible views. Documenting all the potentially useful ones is time-
consuming and expensive.
• An architecture often evolves as the system is incrementally developed and more insights into
the problem domain are gained. Keeping the architecture documents current is often an
overlooked activity, especially with time and schedule pressures in a project.
Structure diagrams define the static architecture of a model
• Class diagrams: Show the classes in the system and their relationships.
• Component diagrams: Describe the relationship between components with well-defined
interfaces. Components typically comprise multiple classes.
• Package diagrams: Divide the model into groups of elements and describe the dependencies
between them at a high level
• Deployment diagrams: Show how components and other software artifacts like processes are
distributed to physical hardware.
• Object diagrams: Depict how objects are related and used at run-time. These are often called
instance diagrams.
• Composite Structure diagrams: Show the internal structure of classes or components in terms of
their composed objects and their relationships.
Behavior diagrams show the interactions and state changes that occur as elements in the model
execute
• Activity diagrams: Similar to flow charts, and used for defining program logic and business
processes.
• Communication diagrams: Called collaboration diagrams in UML 1.x, they depict the sequence of
calls between objects at run-time.
• Sequence diagrams: Often called swim-lane diagrams after their vertical timelines, they show
the sequence of messages exchanged between objects.
• State Machine diagrams: Describe the internals of an object, showing its states and events, and
conditions that cause state transitions.
• Interaction Overview diagrams: These are similar to activity diagrams, but can include other
UML interaction diagrams as well as activities. They are intended to show control flow across
several simpler scenarios.
• Timing diagrams: These essentially combine sequence and state diagrams to describe an object’s
various states over time and the messages that alter the object’s state.
• Use Case diagrams: These capture interactions between the system and its environment,
including users and other systems.