Rational Software Architecture

• UML sequence diagrams
• Models interactions in our product and provides a logical view of that.
• Different components of a sequence diagram are as follows
• Participants
• Participants can be objects or any part of our system. We want to refer in our view.
• Participant name is written as “name of participant: Participant class” For example “theCustomer:Customer”
• Lifeline
• These flow-down from participants And interactions are shown between these lines.
• An interaction occurs when one participant sends a message to another participant.
• A message is an event that is sent from a caller to a receiver.
• A message has a signature or description of a message.
• Synchronous message.
• It is used when a message is sent and sender waits for response.
• Asynchronous Messages
• Are used when a message is sent and sender does not wait for the response and continues its work.
• Destroy participant
• Participant is destroyed by passing delete.
• Time constraints
• Time to perform an operation
• Lost message
• Found message
• Return message
• Guard condition
• Sequence fragments
• Boxes that Surround interactions in a sequence diagram.
• A fragment may be 
• optional(conditional)
• Negative(Destroy object)
• Reference(Reference to another sequence diagram)
• Loop
• Parallel(Runs in parallel with parent fragment).
• Alternate(Alternate operations).
• Assert(Interaction inside fragment must work perfectly or exception will be thrown).
• Break(Break Out of loop).
• Critical sequence fragment(Secured operation).
• Nested message(When a receiving participant Sends the message Further to one or more sources).
• UML structure diagrams
• Structure diagrams
• How the system should be built? what components it should have and how it should be deployed when finished.
• Types of structure diagrams are as follows
• Class diagram
• Describes the concepts of the system.
• Becomes more detailed during the life cycle.
• Purpose is to
• Name and model the concepts of the system.
• Define collaboration between concepts
• Define database structure.
• We can expand our defined details in class diagrams with analysis approaches such as benefits cost analysis.
• Identify the need of interfaces, identify the needs for the data which the system will manage and different types of messages And connections between the components.
• Component diagram
• Describes the physical structure of implementation.
• Shows how the system is divided into components and how they are dependent on each other.
• Part of architect description.
• Purpose is to organise the source code, build executable, and describe the physical database.
• Each executable represents a component.
• Composite structure diagram
• Models classes, their interfaces and internal structures with a hierarchical notation.
• Shows also collaborations between classes.
• Typically used for architecture design.
• Not a widely used notation-Comes with UML 2.0.
• Composite Structure defines the component internals defined in component diagram.
• Defines classes, interfaces and internal structures going even into the variable level of the One module typically used in detailed design work.
• Used in Medicare, Military applications or Space technology.
• Deployment diagram
• Describes Systems hardware topology.
• Part of architecture description
• Purpose is to describe distribution of hardware components and identify the bottlenecks of performance.
• Describe the physical layout of the system and parts like browser, server system, Cloud system, databases, log files etc.
• Describes the hardware topology, Includes definitions for things like what sort of service system application will be having, sort of workstation or working platform, input/output, controls, locations of databases.
• Object diagram
• Shows object instances and their links.
• Used In description of examples about data structures.
• Package diagrams
• Shows Dependencies between larger blocks of items called packages.
• Used in architecture, design and specification
• Shows the hierarchy and connections between different packages Which may third-party libraries.
• These packages are importable in development tools.
• For example, our system may be using a CRM package of external vendor.
• A meta diagram useful for Classifying different diagrams into larger packages.
• Behaviour diagrams
• How system should behave in different use cases.
• Types of behaviour diagrams are
• Activity diagram
• State machine diagram
• Use case diagram
• Interaction diagrams
• What sort of activities or messages should happen when system is functioning.
• Types of interaction diagrams are
• Communication diagram
• Interaction overview diagram
• Sequence diagram
• Timing diagram
• UML design patterns
• Behavioural
• Chain of responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template method
• Visitor
• Creational
• Abstract factory
• Builder
• Factory method
• Prototype
• Singleton
• Structural
• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy