Software Architecture and UML Modeling

RSA (Rational Software Architect) allows saving the current perspective configuration as a new custom perspective. Window > Save Perspective As creates a duplicate you can modify. Window > Create Perspective is not the correct menu path, and perspectives CAN be created.

Sequence diagrams show interactions between objects over time for a specific scenario - this is dynamic behavior (how objects communicate). Static behavior refers to structural elements like class relationships, which sequence diagrams don't depict.

Activity diagrams model workflow processes and can show parallel/concurrent activities. However, they don't assign responsibilities - they lack swimlanes or actor information unless explicitly added with partitions, making it hard to trace back to which objects/people perform which actions.

RSA (Rational Software Architect) can generate HTML reports for model documentation and publishing. While it may interact with other Microsoft Office formats through various plugins, HTML is the native, core reporting format supported directly by RSA's reporting infrastructure.

In aggregation, the 'part' objects can exist independently - if the whole is destroyed, parts survive. In composition, parts have dependent lifecycles - destroying the whole destroys its parts. The false statement is C because it incorrectly claims aggregation has cascade delete behavior.

Use case diagrams support specific relationship types. 'include' is a standard UML relationship where one use case includes another's behavior. 'sub typing' is not the correct term (it's 'generalization'), and 'expand' and 'extract' are not UML use case relationships.

IBM Rational Software Architect (RSA) provides built-in UML transformations for commonly used languages and standards like C++, Java, and WSDL. SmallTalk is an older object-oriented language that is not typically supported out of the box in modern RSA versions due to its limited industry adoption today. The transformation requires additional plugins or custom configuration.

In RSA, a UML project serves as a container that can hold multiple models, allowing architects to organize complex systems into separate logical models within the same project. This flexibility supports large-scale enterprise modeling where different aspects of a system might be separated into distinct models for better management and modularity.

RSA provides a dedicated publish function under the Modeling menu for generating web-ready HTML reports. The 'Modeling >> Publish >> Web' option is the standard, supported method for exporting model documentation to HTML format. The Generate Reports options mentioned in A and B are either for specific report types or not the primary method for web publishing.

Each UML diagram type serves a specific purpose: State diagrams excel at tracking individual object behavior across use cases (A), Interaction diagrams (sequence/collaboration) show message flow between multiple objects within a single use case (B), and Activity diagrams model processes involving multiple objects across multiple use cases (C). All three statements accurately describe appropriate uses of these diagram types.

The Rational Unified Process (RUP) defines four sequential phases: Inception, Elaboration, Construction, and Transition. The selected option correctly lists these four phases, despite a minor spelling error in 'Ellaboration'.

Sequence diagrams emphasize the time-based ordering of messages between objects, showing the flow from top to bottom. Collaboration diagrams (now called communication diagrams in UML 2.x) focus on the structural relationships between objects and the messages exchanged, but do not inherently represent time ordering. Option B correctly captures this key distinction.

TOGAF guidelines specify that architects should first look for reusable building blocks from their Enterprise Continuum to leverage existing organizational assets before creating new custom components or looking externally.

Qualitative criteria in architecture evaluation refer to non-measurable, descriptive attributes that assess quality characteristics. Security is inherently qualitative; it evaluates protection capabilities, not numeric metrics. Options A (defects per unit), B (cost), D (functionality), and E (timeline) are either quantitative metrics or functional aspects, not qualitative quality criteria.

In TOGAF and enterprise architecture practice, application systems should be described as logical groupings of business capabilities or functions they provide. This abstraction level focuses on what the system delivers for the business, not implementation details like schemas or technical diagrams. Computer systems (A) is too generic, while schemas (C) and data-flow diagrams (D) are implementation-specific views.

Application functionality is a functional requirement, not a qualitative quality criterion. Qualitative criteria assess quality attributes like availability, security, reliability: how well the system performs its function. Transaction volume (A) is quantitative. Availability, reliability, and security (B, D, E) are genuine qualitative quality characteristics describing non-functional aspects.

In TOGAF, Application Architecture describes the structure and behavior of applications, but the actual detailed design of those application systems is part of the system design phase rather than the enterprise architecture phase itself. Also, applications are generally not stable and unchanging over time, which makes that statement also false.

In TOGAF's ADM, architecture phases are iterative. If application architecture work reveals significant business architecture gaps or changes, the correct practice is to revisit and refine the business architecture phase rather than force alignment through technology adjustments or workarounds. This ensures business-IT alignment. Options B, C, D, and E represent workarounds or governance circumventions that don't address the root architectural misalignment.

Gap analysis in architecture identifies the difference between current state (baseline) and target state. Its primary purpose is finding functions or capabilities that are missing entirely or duplicated/overlapping in the current architecture. This informs decisions about what needs to be built, bought, or consolidated. Options A, C, D, and E describe other architecture activities, not the core purpose of gap analysis.

According to TOGAF, Architecture Building Blocks (ABBs) define the required capability and what functionality is needed, whereas Solution Building Blocks (SBBs) define how that functionality will be implemented and with what products.