Section1: Identify Design Elements (17%) 1.

Identify classes and subsystems Elaboration phase

This task explains how to identify Subsystems, Classes, interfaces, Events and Signals. U/C Analysis results in Analysis Classes captures responsibility (functional requirements)this is analysis model ===> Design Model Elements ===> Design Classes (Nonfunctional requirements) Every analysis class part of analy model should be associated with @least 1 design class in design model. Design Model is dependencies with analysis model and not vice versa. Design Model is close to implementation model. When analysis class is complex, it has to be mapped to a design subsystem. It collaborates in such a way that the clients of the subsystems can be completely unaware of the internal design even as the service is being used.

Subsystems has only interfaces. interfaces provide a layer of encapsulation, allowing the internal design of the subsystem to remain hidden from other model elements

If the collaborations can be completely contained within a package along with the collaborating classes, a subsystem can provide a stronger form of encapsulation than that provided by a simple package. Good choice is choice of subsystems over simple packages Design elements like classes (represent a set of rather fine-grained responsibilities), subsystems (coarse-responsibility of team of dev), active classes (represent threads in the system & resolves concurrency conflicts.eg financial transaction) ==> internal representatives of external physical devices These "device driver" classes serve not only to monitor and control the corresponding physical devices but they also isolate the rest of the system from the specifics of the devices. Because of their capacity to simply and elegantly resolve concurrency conflicts, active classes are also useful as guardians of shared resources. active classes or capsules (responsibility of single designer), interfaces (allows to capture the seams of systems), Events, Signals. classes & Subsystems units. Control and CM. 2. Identify subsystem interfaces To identify the design elements which formalize the seams in the system. used to define the interfaces for subsystems. Interfaces are important for subsystems because they allow the separation of the declaration of behavior (the interface) from the realization of behavior. This decoupling helps in retaining precise definitions of the 'contracts' between these different parts

**For each subsystem, identify a set of candidate interfaces. Then identify the responsibility. This responsibility is then refined by determining what information must be provided by the 'client' and what information is returned when the collaboration is complete; ensure there is return value from the operation executed. Repeat this until all operations which will be realized group operations together according to their related responsibilities. Small group over large group. Smaller group would have cohesive set of common responsibility. Look for reuse. Grouping reuse. *&)Look for similarities between interfaces The goal is to maintain the cohesiveness of the interfaces while removing redundant operations between interfaces Define interface dependencies provides useful coupling information. Ensure the return type of the interface operation is a simple data type. In cases where the parameters are objects that realize a particular interface, define dependency relationships between the interface and the interfaces on which it depends. Map the interfaces to subsystems. create realization associations between the subsystem and the interfaces Define the behavior specified by the interfaces If the operations on the interface must be invoked in a particular order (e.g. the database connection must be opened before it can be used) shd follow that. Package the interfaces interfaces should be grouped into one or more packages. If each interface is realized by a single subsystem, the interfaces can be placed in the same package with the subsystem. If the interfaces are realized by more than one subsystem, they should be placed within a separate package

Identify Capsule Protocols

Protocols are ||| to interfaces.define asynchronous communication where as interfaces are synchronous messaging. For each capsule, identify a set of in and out signals same as ** but rename operation to signal Look for similarities between protocols *&) use protocols instead of interfaces Map the protocols to capsules. Use capsules instead of subsystems. Once protocols have been identified, create ports on the capsules which realize the protocols. Define the behavior specified by the protocols use protocols instead of interfaces Package the protocols. changes to protocols are always architecturally significant. To manage this, the protocols should be grouped into one or more packages owned by the software architect. 3. Update the organization of the Design Model as new elements are added to design model, re-packaging the element is necessary. It improves cohesion with in the same package and reduces coupling between packages. Make the subsystems independent

that any team can easily use the same. Complete independence is not possible but loose coupling is good between packages it helps while building a complex systems. As the existing packages grow, split into several packages with high cohesion and low coupling between packages Some element may to be difficult to place in a specific package, as the same element could be used by 2 different packages. Solution: Split the elements based on the responsibilities performed (or) place the element in the lower layer, so the higher layers can depend upon it.
During Architectural Analysis, the focus was on the upper-level layers (that is, the application and business-specific layers). During Identify Design Elements, the focus is on the lowerlevel layers. Layering considerations: Upper layers affected by requirements changesLower

layers affected by environment changes.Goal is to reduce coupling and to ease

maintenance effort. Most boundary classes tend to appear at the top, control servics layer
or middle entity at lower layers

Partitioning Section 2: Identify Design Mechanisms (8%) 1. Categorize clients of analysis mechanisms This task describes how to refine Analysis Mechanisms into Design Mechanisms. Activity: Refine the architecture Phase: Elaboration Main output from Identify Design Mechanism is Design Model & SAD. Both are i/p as well as o/p

Design Model elements are classes, packages and subsystems Analysis mechanisms provides services used by analysis classes. Capture the requirements for the yet to be designed system without thinking of the implementation details yet. Steps for refining the analysis mechanisms:

Identify the clients of each analysis mechanism performance analysis mechanisms between 2 clients would be differnt Identify characteristic profiles for each analysis mechanism mechanisms will require estimates of the number of instances to be managed, and their expected size in terms of the expected number of bytes. The movement of large amounts of data through any system will create tremendous performance issues which must be dealt with. Group clients according to their use of characteristic profiles group similar characteristics profile; identify a design mechanism based on each such need. This will help us freeze the initial cut at the design mechanisms. An example analysis mechanism, "interprocess communication", may map onto a design mechanism "object request broker". Different characteristic profiles will lead to different design mechanisms which emerge from the same analysis mechanism. The design mechanisms are refinements of the analysis mechanisms, based on different characteristic profiles.

Proceed bottom up and make an inventory of the implementation mechanisms that you have at your disposal. Eg - Mechanisms offered by a middleware product or
component framework. Mechanisms offered by operating systems. Mechanisms offered by a component. Mechanisms offered by a class library, legacy code etc Determine where existing implementation mechanisms can be used and where new implementation mechanisms need to be built. 2. Document architectural mechanisms

Section 3: Distribution (17%) 1. Define the network configuration (& Topology of n/w). Will help find the degree of distribution possible in the system. This task define Distribution is a generic example of a high level deployment model The focus of the Describe Distribution (analysis mechanism) activity is on developing the Deployment View of the architecture. This activity is really only required for distributed systems. DD can be skipped if there is only 1 node. Phase: Elaboration Activity: Refine the Architecture. Task: Describe Distribution. Process viewPerformance, scalability, throughput Deployment View is subset of deployment model deployment architecture for a distributed system in terms of physical nodes and their interconnections Distribution patterns: Client/server 3 tier(= divided into 3 logi partitions app, business (located on specialized servers) & data servcies (needs high-performance, high-bandwidth nodes),Fat client (eg: database), Fat server (eg: web server), Distributed, peer to peer.

During Task: Architectural Analysis, an initial Deployment Model was defined. Early in the Elaboration phase, the deployment view is usually quite preliminary, but by late Elaboration it should be well-defined Distribution demands in the problem domain Selected deployment configuration Required resources (nonfunctional requirements) The need for fault tolerance (nonfunctional requirements) Scalability and flexibility concerns (nonfunctional requirements) Economic concerns Node: Represents a run-time computational resource. Generally has at least memory and often processing capability. Connectors can be drawn between nodes. The Deployment Model has 1 or * nodes, devices, connectors. Following roles use deployment models: software architect, Designer, SA, DM, PM.

Following needs to be captured: physical layout, nodes on n/w, bandwidth, redundant pathways. 1* purpose of nodes including workstation nodes, server nodes, specialized configuration, specialized processors. 2. Allocate processes to nodes Distribute the workload of the system. Logical deployment: logical elements are mapped to nodes, Physical deployment: files are mapped to nodes. Distribution is an area where sum = < sum of its parts. For distribution, consider the following: node capacity, fault tolerance, throughout, communication channels, response time requirements, routing & h/w availability. Elements that interact more need to be part of same node. Distribution of process across 2 or more nodes needs. To simplify distribution use Cluster grp of servers includes functionalilty such as load balancing / failover and container: deployment view should describe how system elements are deployed to containers. 3. Define the distribution mechanism

Section 4: Use Case Design (22%) how to refine the products of Use-Case Analysis by developing Design-level Use-Case Realizations. To refine u/c realization & requirements. Behaviour of the system can be described using interactions & collaborattions. Task U/C Design uses interaction through sequence diagram (described by synchronous messaging)

UC realization is how an U/C is implemented. This includes a textual description, class diagrams, interaction diagrams (Sequential & Communication diagrams). By doing realization, use cases can be managed separately from their realizations This is the order of execution:

During this task, Use-Case Design, any applicable design mechanisms are incorporated into the use-case realizations.

1. Describe interaction among design objects 2. Simplify sequence diagrams using subsystems 3. Describe persistence-related behavior The object that instantiates a persistent object is sometimes called a factory object. Retrieving objects before they are needed is one of the main performance problems caused by simplistic persistence mechanisms.

Concurrency control may be implemented in a number of different ways, including resource locking, semaphores, shared memory latches, and private workspaces. 4. 5. 6. 7. Refine the flow of events description 8. Unify classes and subsystems As use cases are realized, you need to unify the identified design classes and subsystems to ensure homogeneity and consistency

Section 5: Subsystem Design (11%) 1. Distribute subsystem behavior to subsystem elements 2. Document subsystem elements 3. Describe subsystem dependencies

Section 6: Class Design (25%) 1. Create Initial Design Classes 2. Define Operations 3. Define Methods 4. Define States 5. Define Attributes 6. Define Dependencies 7. Define Associations 8. Define Internal Structure 9. Define Generalizations 10. Resolve Use-Case Collisions 11. Handle Nonfunctional Requirements in General