Chapter #7 UML Architecture Diagrams— Software Design and Architecture Specialization University of Alberta
Software architecture is the fundamental design of a software system, encompassing the elements, their functions, and their relationships. It takes into account factors like the system’s purpose, target audience, user requirements, and deployment environment. Having a well-defined software architecture is crucial, especially for large systems, as it provides a clear foundation for development and offers several advantages:
- Higher productivity: A well-defined architecture coordinates the work of the software team, guiding the implementation of features and addressing potential issues, reducing conflicts and unnecessary work.
- Improved evolution: Software architecture applies design principles that make it easier to implement changes and identify defects in the software, ensuring the system’s adaptability and maintainability.
- Enhanced quality: It considers the needs and perspectives of all stakeholders, resulting in a software system that better meets their requirements.
Stakeholders, including software developers, project managers, clients, and end users, play a vital role in the software architecture process. Each stakeholder has their own perspective and benefits from software architecture:
- Software developers benefit from the guidance and organization provided by software architecture in creating and evolving the software.
- Project managers use software architecture to identify risks, manage tasks, and understand task dependencies and the impact of changes on the project.
- Clients rely on software architecture for effective communication, ensuring that their needs are met and that they understand what they are investing in.
- End users may not be concerned with the system’s design but expect it to work well for their needs.
UML (Unified Modeling Language) diagrams are a common way to represent software architecture, aiding in the visualization and communication of the system’s structure and design.
Kruchten’s 4+1 View Model
To comprehensively understand and develop a software system, multiple perspectives are essential. These perspectives encompass various considerations:
- Logical View: This perspective focuses on the functionality of the software, emphasizing what the system does to fulfill the client’s objectives. It considers the required objects and their interactions.
- Process View: Examining how efficiently the software operates and how subprocesses interact, this perspective delves into performance and scalability considerations. It concentrates on the processes implemented by the logical view’s objects.
- Development View: This perspective pertains to the implementation and hierarchical structure of the software. It is influenced by the choice of programming languages, which imposes constraints on the development process.
- Physical View: The physical components of the software and their interactions, as well as deployment considerations, are the focal points of this perspective. It addresses how the system functions in a real-world environment.
All these views are aligned with the client’s requirements and desired capabilities. Scenarios, representing use cases and end-user tasks, provide context and detail to support the understanding of these views. Philippe Kruchten’s 4+1 View Model combines these four views with scenarios to offer a comprehensive framework for addressing critical considerations in software architecture.
Scenarios
Scenarios in software architecture are aligned with use cases and user tasks, demonstrating the interplay of the logical, process, development, and physical views. Each scenario comprises a script outlining the sequence of interactions between objects, processes, hierarchies, and nodes. These scripts interconnect the key elements from each view, providing a holistic understanding of the software system. The 4+1 view model emphasizes the interdependence of the views, highlighting how they complement one another. It is a versatile framework that can be adapted to various situations, enabling a comprehensive understanding of software architecture. Viewing complex problems from multiple perspectives enhances the adaptability and versatility of the software system.
Component Diagrams
UML component diagrams focus on the structure of a software system, depicting independent, encapsulated units known as components and their interactions. They provide a high-level view, emphasizing relationships between components rather than detailed attributes or methods. These diagrams offer a static representation of the system at a specific point in its development. Components are depicted with ball connectors, representing provided interfaces for interaction, and socket connectors, representing required interfaces that need to be fulfilled by other components. Assembly relationships are illustrated when a component’s provided interface matches another’s required interface. To create a component diagram, one needs to identify the main system objects, relevant libraries, and the relationships between the components.
Package Diagrams
Package diagrams in software modeling are used to illustrate how elements are grouped into packages based on their relationships or functionalities. A package serves as a container for related elements, enabling the organization of software components, classes, or user tasks. It also establishes a namespace, allowing elements within the package to be uniquely identified using a fully qualified name.
These diagrams offer a visual representation of the packages and their interdependencies, aiding in the conceptualization of a complete system. They facilitate the organization of a system into coherent packages, providing a high-level view of how elements are grouped and how different packages are interdependent.
Deployment Diagram
UML deployment diagrams are instrumental in visualizing the detailed deployment aspects of a software system, encompassing not just code but also various components like libraries, installers, and configuration files. They play a critical role in understanding the files, executables, and their associated environments required for the software to run effectively.
Deployment diagrams can be highly specific, considering particular hardware devices, or more general, focusing on supported operating systems. These specifics vary based on the deployment environment. For instance, software intended for Linux, MacOS, or Windows may have variations in deployment details.
These diagrams primarily deal with artifacts, which are tangible outcomes of the software development process. Artifacts may include executables, installers, libraries, and multimedia assets. They represent the final pieces needed for assembling the software.
There are two types of deployment diagrams:
1. Specification-Level Diagrams: These provide an overview of artifacts and deployment targets without referencing specific machine names. They offer a general perspective of the deployment environment.
2. Instance-Level Diagrams: These are more specific and map specific artifacts to designated deployment targets, even identifying specific machines and hardware devices. They are typically used to highlight differences in deployments between development, staging, and release builds.
In creating deployment diagrams, it is crucial to use the correct notation for various elements. The key element in a deployment diagram is the “node,” representing deployment targets containing executable artifacts. Hardware devices are also represented as 3D boxes, marked with a “device” tag for differentiation.
Relationships between deployment targets can be represented with solid lines, signifying communication paths, often associated with specific communication protocols. The hierarchy of deployment targets is vital, starting from the highest level (e.g., application name) down to the device and operating system, outlining the necessary environment for running the application.
Deployment diagrams serve to provide consistency and organization in deployments, reducing the risk of system failures. They assist in tracking the required files and executables for deployment and software execution. These diagrams can be either highly specific to particular deployment machines or more general to encompass a range of execution environments. They offer a high-level overview of essential components, aiding in the effective deployment of software systems.
Activity Diagrams
UML activity diagrams serve to represent the flow of control from one activity to another within a software system, effectively capturing the dynamic behavior of the system and enabling the depiction of branching into alternative flows. Activities in an activity diagram are the actions that drive the execution flow within the system, potentially leading to the execution of other actions or the modification and creation of objects.
To create an activity diagram, the following steps are essential:
1. Identify the activities within the system.
2. Identify the corresponding conditions or triggers for these activities.
The activity diagram consists of several key components:
1. Start and End Nodes: Represented as labeled circles, these nodes indicate the beginning and ending activities of the diagram. They serve to initiate and conclude the control flow of the application.
2. Intermediate Activities: Shaped as ovals, these activities depict the various stages or actions that alter the state of the system before its conclusion.
3. Decision Nodes: Represented as diamonds, decision nodes indicate the possibility of multiple outcomes based on the evaluation of conditions. They help in mapping alternative paths in the control flow.
Activity diagrams also facilitate the representation of concurrent activities occurring in parallel, with the ability to branch into multiple flows and converge back into a single flow. Forks in the flow allow activities to happen simultaneously, with the possibility of joining back into a single flow. Swimlanes are used to categorize activities based on their occurrence or the user roles involved, providing a clear visual separation of different categories.
These diagrams enable the visualization of the activities and associated conditions within the system, offering insights into the sequential order of encountered features, while also accommodating the consideration of alternative flows within the system. They provide a comprehensive understanding of the system’s behavior and serve as a valuable tool for system analysis and design.
Ibrahim Can Erdoğan
