Role-Based Guide to the RUP Architect

2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout the project. A software architect coordinates some of the key design decisions in terms of technologies, structure, and organization of the software system. The software architect's view is breadth, as opposed to depth.

3 Architect Architect focuses only on the architecturally significant requirements and the corresponding architecturally significant design decisions “Architecturally significant" means the ones that will have a long and lasting effect on the system performance, quality, and scalability, as opposed to other design decisions that will be made during the construction of the system. Architect does not bear the responsibility of making all design decisions.

4 A Person or a Team? A project with more than 30 people may want to create an architecture team The goal of a team is to have a good mix of talents, covering a variety of experience and sharing a common understanding of software engineering process. Software architecture is a full-time function, with staff permanently dedicated to it.

5 A Vertex of Communication Communication between project management & development –Architect and project manager need to communicate constantly –Architect plays a major role in planning the contents of an iteration, in identifying and addressing technical risks, and in helping the project manager with strategic and tactical changes Communication between internal parties & external stakeholders –Architect will extract the architecturally significant requirements that will contribute to shape the system. Communication between various development teams –Architects will also play a role of communication and coordination, on the technical front, between various development teams –They will make sure that interfaces are defined and respected

6 Minimize Communication among Dev Team

7 Architecture (1) Software architecture encompasses the set of significant decisions about the organization of a software system: –Selection of the structural elements and their interfaces, by which a system is composed –Behavior as specified in collaborations among those elements –Composition of these structural and behavioral elements into larger subsystems –Architectural style that guides this organization

8 Architecture (2) Software architecture is also concerned with –Usage –Functionality –Performance –Resilience –Reuse –Comprehensibility –Economic and technology constraints and tradeoffs –Aesthetic concerns

9 Architecture (3) Architecture comprises the software system's most important building blocks and their interfaces, that is: –subsystem, –interfaces of the subsystems, –and the most important components and their interfaces Architecture provides a skeleton structure of the system, comprising perhaps 10 to 20 percent of final amount of code Since the architecture defines the system's building blocks or components, it enables us to more accurately assess the effort needed to complete the project.

10 Three Options for a Client/Server Architecture During Inception, identify the type of architecture you intend to have and make implementations of necessary elements to the architecture to understand what risks you are facing. Here you see three options for a client/server architecture, each with vastly different requirements for tooling, competency, and complexity, and with different ability to address existing and future requirements on functionality, operation, and maintenance cost.

11 The Art of Compromise. Architects need to consider and balance the impact along a number of different dimensions when making architectural decisions. This forces the architects to constantly make difficult tradeoffs.

12 Models and Views

13 Models and Views A logical view –showing the various elements of the software and their structure: classes, packages, and so on. A process view –showing the parallelism between various entities, and how communication and synchronization are achieved. An implementation view –showing how the implementation elements (source code files, executable, etc) are organized in the development environment.

14 Models and Views A deployment view –showing how physically at runtime the various runtime components are replicated and deployed, and how they communicate. A use-case view –capturing the most significant requirements: use cases or parts of use cases that have some great impact on the architecture, as well as significant nonfunctional requirements. This may include use- case realizations to illustrate how the system works.

15 Software Architecture Document Main responsibility of architect is to describe the architecture of the system in a major artifact called the Software Architecture Document (SAD). SAD may be only part of the design that is described in an actual document, mostly in UML models and in code itself. SAD is organized along a set of views, chosen among the ones we listed earlier, or any other suitable for the project.

16 Executable Architectural Prototype Architect is responsible for driving implementation of this prototype that will evolve to become the complete system. The prototype is used to: –validate the architecture, –demonstrate that all major technical risks have been retired, –serve as a baseline for the rest of the development.

17 Architect During Inception Working with the emerging vision: –An architect evaluate possible implementation strategies and feedback feasibility to the requirements work, and costs to management. As the system takes shape: –A possible architecture is defined or prototyped to assess its effectiveness: a proof-of-concept prototype for candidate Architecture. Certain delicate parts of the system may also be prototyped to prove a concept feasible, or to help drive a decision to develop the system - or not develop it

18 Architect During Elaboration Architect has the most crucial role, and often several persons will be involved. An objective of Elaboration is to produce SAD and validate choices made by developing an executable architectural prototype The milestone is called the Lifecycle Architecture (LCA) Milestone, and architects could baseline an architecture. Architectural effort may result in a revision of the requirements and the vision. –For example, our new prototype may show that we have some performance issues to be addressed.

19 Architect During Construction As in building architecture: –SW architects are overseeing implementation of the rest of system, making sure the original architectural intent is not compromised Architect will make sure that guidelines are followed, or capturing new information in the guidelines. Involved in design reviews: –Architects can also identify further opportunities for reuse or acquisition of ready-made software.

20 Architect During Transition Architect is involved in critical decisions about major defects: –What to fix and how, especially vigilant so that hasty or uninformed decisions that could fix one subsystem but break another one are not made. Lots of mistakes can be made in that last stretch to the finish line, wiping out the benefits of architectural work.

21 Architect's Activities in the RUP Besides SAD and architectural views, the RUP describes several activities for the architect such as: 1. Working with the requirements and the project management Prioritize Use Cases Architectural Analysis Construct an Architectural Proof-of-Concept Prototype 2. Refining the architecture Identify Design Mechanisms Identify Design Elements Incorporate Existing Design Elements Structure Implementation Model Describe Distribution and Describe the Runtime Architecture

22 Architect's Activities in the RUP (cont.) Besides SAD and architectural views, the RUP describes several activities for the architect such as: 3. Maintaining the architectural integrity Develop Design Guidelines Develop Programming Guidelines Review the Architecture

23 Overview of the Architect's Activities