Analysis and Design Guideline
Step 1: Define Use case, Actor and use case model (use case model means .mdl, use case specification document and supplementary specification document)
Actor: An actor is someone or something external to the system, which interact with the system.
Use case: A use case is a set of scenarios tied together by a common user goal.
Scenario: A scenario is a sequence of steps describing an interaction between a user and a system. So if we have a Web-based on-line store, we might have a Buy a Product scenario that would say this:
- The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up e-mail.
Relationship between use cases:
Extend: The extend-relationship connects an extension use case to a base use case. A relationship from one use case to another, specifying how the behavior defined for the first use case can be inserted into the behavior defined for the second use case. The extension use case is often abstract, but does not have to be. One thing important is that for executing extended use case must be require actor intervention.
You can use the extensions for several purposes:
- To show that a part of a use case is optional, or potentially optional, system behavior. In this way, you separate optional behavior from mandatory behavior in your model.
- To show that a sub flow is executed only under certain (sometimes exceptional) conditions, such as triggering an alarm.
- To show that there may be a set of behavior segments of which one or several may be inserted at an extension point in a base use case. The behavior segments that are inserted (and the order in which they are inserted) will depend on the interaction with the actors during the execution of the base use case
Include: The include-relationship connects a base use case to an inclusion use case. The inclusion use case is always abstract. It describes a behavior segment that is inserted into a use-case instance that is executing the base use case. The base use case has control of the relationship to the inclusion and can depend on the result of performing the inclusion, but neither the base nor the inclusion may access each other’s attributes. The inclusion is in this sense encapsulated, and represents behavior that can be reused in different base use cases.
Can be used the include-relationship to:
- Factor out behavior from the base use case that is not necessary for the understanding of the primary purpose of the use case, only the result of it is important.
- Factor out behavior that is in common for two or more use cases.
Generalization: A parent use case may be specialized into one or more child use cases that represent more specific forms of the parent. Neither parent nor child is necessarily abstract, although the parent in most cases is abstract. A child inherits all structure, behavior, and relationships of the parent. Children of the same parent are all specializations of the parent. This is generalization as applicable to use cases
Generalization is used when you find two or more use cases that have commonalities in behavior, structure, and purpose. When this happens, you can describe the shared parts in a new, often abstract, use case, that is then specialized by child use cases.
Content of Use case Specification Document: This document contains brief description of use case, pre condition to execute use case, basic and alternate flow of use case and post condition of the use case.
Content of Supplementary Specification: This document contains FURPS of RUP.
F → Non Functional Requirements
U → Usability
R → Reliability
P → Performance
S → Supportability
Step 2: Define Key Abstraction
Abstraction: The essential characteristics of an entity that distinguish it from all other kind of entities. An abstraction defines a boundary relative to the perspective of the viewer.
Key Abstraction: A key abstraction is a concept, normally uncovered in Requirements that the system must be able to handle. Usually all the actors are the key abstraction and the use cases having abstraction level of hierarchy is also considered to be Key Abstraction. Source of Key Abstraction
- Domain knowledge
- Domain Model, or the Business Model (if one exists)
Step 3: Define Analysis Mechanism
Package: Package is a model element that contains other model element or a package is a general-purpose mechanism for organizing elements into groups. The only relationship exists between package is dependency which means
- Changes to the Supplier package may affect the Client package.
- The Client package cannot be reused independently because it depends on the Supplier package.
Analysis mechanisms are used during analysis to reduce the complexity of analysis and to improve its consistency by providing designers with a shorthand representation for complex behavior. Sample Analysis Mechanisms are
- Communication (IPC and RPC)
- Message routing
- Transaction management
- Process control and synchronization (resource contention)
- Information exchange, format conversion
- Error detection / handling / reporting
- Legacy Interface
Step 4: Define Use case Realization
Use case Realization: A use-case realization describes how a particular use case is realized within the design model, in terms of collaborating objects.
Benefits: Provides traceability from Analysis and Design back to Requirements
Step 4a: Define Analysis Classes
- Intermediates between the interface and something outside the system
- Several Types
- User interface classes
- System interface classes
- Device interface classes
- One boundary class per actor/use-case pair
Entity Class: An entity class is a class used to model information and associated behavior that must be stored. Entity objects (instances of entity classes) are used to hold and update information about some phenomenon, such as an event, a person, or some real-life object. They are usually persistent, having attributes and relationships needed for a long period, sometimes for the life of the system. Finding Entity Classes
- Use use-case flow of events as input
- Key abstractions of the use case
- Traditional, filtering nouns approach
- Underline noun clauses in the use-case flow of events
- Remove redundant candidates
- Remove vague candidates
- Remove actors (out of scope)
- Remove implementation constructs
- Remove attributes (save for later)
- Remove operations
Control Class: A control class is a class used to model control behavior specific to one or a few use cases. Control objects (instances of control classes) often control other objects, so their behavior is of the coordinating type. Control classes encapsulate use-case specific behavior. Finding Control Classes
- As analysis continues, a complex use case’s control class may evolve into more than one class.
Restriction of Boundary Class:
The following are allowable:
- Communicate associations between two Boundary classes, for instance, to describe how a specific window is related to other boundary objects.
- Communicate or subscribe associations from a Boundary class to an Entity class, because boundary objects might need to keep track of certain entity objects between actions in the boundary object, or be informed of state changes in the entity object.
- Communicate associations from a Boundary class to a Control class, so that a boundary object may trigger particular behavior.
Restriction of Control Class:
The following are allowable:
- Communicate or subscribe associations between Control classes and Entity classes, because control objects might need to keep track of certain entity objects between actions in the control object, or be informed of state changes in the entity object.
- Communicate associations between Control and Boundary classes, allowing the results of invoked behavior to be communicated to the environment.
- Communicate associations between Control classes, allowing the construction of more complex behavioral patterns.
Restriction of Entity Class: Entity classes should only be the source of associations (communicate or subscribe) to other entity classes. Entity class objects tend to be long-lived; control and boundary class objects tend to be short-lived. It is sensible from an architectural viewpoint to limit the visibility that an entity object has of its surroundings, that way, the system is more amenable to change
Step 4b: Draw View of Participating Classes (VOPC) Class Diagram
Association: The semantic relationship between two or more classifiers that specifies connections among their instances or a structural relationship, specifying that objects of one thing are connected to objects of another.
Aggregation: A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.
Association or Aggregation:
- If two objects are tightly bound by a whole-part relationship
- The relationship is an aggregation.
- If two objects are usually considered as independent, although they are often linked
- The relationship is an association.
Composition: Whole and part relationship having strong ownership of whole. Use when cascade delete functionality exists between classes.
Step 4c: Draw Sequence Diagram between VOPC:
Lifeline: Each object appearing on a sequence diagram contains a dashed, vertical line, called a lifeline, which represents the location of an object at a particular point in time. The lifeline also serves as a place for messages to start and stop and a place for the focus of control to reside.
Message: A message represents the communication between objects indicating that an action will follow. The message icon is a horizontal, solid arrow connecting two lifelines together.
Self Message: The message to self appears as a message that returns to itself.
Return: The return arrow may be suppressed since it is implicit at the end of activation.
Step 5: Identify Design Elements:
- Identify classes and subsystems
- Identify subsystem interfaces
- Update the organization of the Design Model
Step 6: Identify Subsystem.
- Completely encapsulate behavior
- Represent an independent capability with clear interfaces (potential for reuse)
- Model multiple implementation variants
Packages versus Subsystems
- Provide behavior Don’t provide behavior
- Completely encapsulate their contents Don’t completely encapsulate their contents
- Are easily replaced May not be easily replaced
- ordered, configured, or delivered
- developed, as long as the interfaces remain unchanged
- deployed across a set of distributed computational nodes
- changed without breaking other parts of the systems
- partition the system into units which can provide restricted security over key resources
- represent existing products or external systems in the design (e.g. components)
- Look at object collaborations.
- Look for optionality.
- Look to the user interface of the system.
- Look to the actors.
- Look for coupling and cohesion between classes.
- Look at substitution.
- Look at distribution.
- Look at volatility
- Classes providing complex services and/or utilities
- Boundary classes (user interfaces and external system interfaces)
- Communication software
- Database access support
- Types and data structures
- Common utilities
- Application-specific products
Step7: Identifying Interfaces
- To identify the interfaces of the subsystems based on their responsibilities
- Identify a set of candidate interfaces for all subsystems.
- Look for similarities between interfaces.
- Define interface dependencies.
- Map the interfaces to subsystems.
- Define the behavior specified by the interfaces.
- Package the interfaces.
Step 8: Drawing Class Diagram
Relationship: All Analysis level relationship is applicable to design classes.
Generalization: Parent-child relationship between classes.
Dependency: A dependency exists between two elements if changes to the definition of one element (the supplier) may cause changes to the other (the client).
|«call»||The source calls an operation in the target.|
|«create»||The source creates instances of the target.|
|«derive»||The source is derived from the target.|
|«instantiate»||The source is an instance of the target. (Note that if the source is a class, the class itself is an instance of the class; that is, the target class is a metaclass).|
|«permit»||The target allows the source to access the target’s private features.|
|«realize»||The source is an implementation of a specification or interface defined by the target (page 69).|
|«refine»||Refinement indicates a relationship between different semantic levels; for example, the source might be a design class and the target the corresponding analysis class.|
|«substitute»||The source is substitutable for the target (page 45).|
|«trace»||Used to track such things as requirements to classes or how changes in one model link to changes elsewhere.|
|«use»||The source requires the target for its implementation.|
Assertion: An assertion is a Boolean statement that should never be false and, therefore, will be false only because of a bug.
Pre-condition: A pre-condition is a statement of how we expect the world to be before we execute an operation. We might define a pre-condition for the “square root” operation of input > = 0. Such a pre-condition says that it is an error to invoke “square root” on a negative number and that the consequences of doing so are undefined.
Post-condition: A post-condition is a statement of what the world should look like after execution of an operation. For instance, if we define the operation “square root” on a number, the post-condition would take the form input = result * result, where result is the output and input is the input value. The post-condition is a useful way of saying what we do without saying how we do it—in other words, of separating interface from implementation.
Exception: An exception occurs when an operation is invoked with its pre-condition satisfied yet cannot return with its post-condition satisfied.
Invariant: An invariant is an assertion about a class. For instance, an Account class may have an invariant that says that balance == sum (entries. amount ()). The invariant is “always” true for all instances of the class. Here, “always” means “whenever the object is available to have an operation invoked on it.”
Derived Properties: Derived properties can be calculated based on other values. Symbol of representing derived properties is “/”.
Read-Only: Can be used this keyword to mark a property that can only be read by clients and that cannot be updated.
Frozen: A property is frozen if it cannot change during the lifetime of an object; such properties are often called immutable.
Qualified association: A qualified association is the UML equivalent of a programming concept variously known as associative arrays, maps, hashes, and dictionaries.
Single classification: In single classification, an object belongs to a single type, which may inherit from super types.
Multiple classifications: In multiple classifications, an object may be described by several types that are not necessarily connected by inheritance.
Dynamic classification: Dynamic classification allows objects to change class within the sub typing structure.
Static classification: static classification does not. With static classification, a separation is made between types and states; dynamic classification combines these notions.
Association Class: Association classes allow you to add attributes, operations, and other features to associations. It is applicable when the multiplicity is many to many.
Template (Parameterized) Class:
Step 9: Draw Sequence Diagram
Types of Message: →
Simple Message: For messages with a single thread of control, one object sends a message to a passive object.
Synchronous Message: In synchronous messages, the operation proceeds only when the client sends a message to the supplier and the supplier accepts the message. The client runs until it sends the message; it then waits for the supplier to accept it. The client continues to wait until the message is accepted.
Balking Message: In balking synchronization, the client can pass a message only if the supplier is immediately ready to accept the message. The client abandons the message if the supplier is not ready.
Timeout Message: In timeout synchronization, the client abandons a message if the supplier cannot handle the message within a specified amount of time.
Asynchronous Message: Asynchronous communication occurs when the client sends a message to the supplier for processing and continues to execute its code without waiting for or relying on the supplier’s receipt of the message.
Procedure Call: The entire nested sequence is completed before the outer level sequence resumes. This can be used with ordinary procedure calls as well as with concurrently active objects when one of them sends a signal and waits for a nested sequence of behavior to complete.
Deletion of a participant is indicated by big X. A message arrow going into the X indicates one participant explicitly deleting another; an X at the end of a lifeline shows a participant deleting itself.
Guard: Guards are a conditional expression placed in square brackets and indicate that the message is sent only if the guard is true.
Step 10: Document Analysis-Class-To-Design-Element Map
|Analysis Class||Design Class|
Step 11: Identification of Reuse Opportunities
Patterns and Frameworks:
- Provides a common solution to a common problem in a context
- Analysis/Design Pattern
- Provides a solution to a narrowly scoped technical problem
- Provides a fragment of a solution, or a piece of the puzzle
- Defines the general approach to solving the problem
- Provides a skeletal solution, whose details may be analysis/design patterns
Step 12: Document Design and Implementation Mechanisms.
Step 13: Describe the Run-time Architecture
- Define the purpose of the Describe the Run-time Architecture activity and when in the lifecycle it is performed
- Demonstrate how to model processes and threads
- Explain how to model what classes and subsystems are mapped to processes and threads
- Define the rationale and considerations that support architectural decisions
Realizing Concurrency: Concurrency Mechanisms:
- To support concurrency, a system must provide for multiple threads of control
- Common concurrency mechanisms
- Multiple CPUs execute concurrently
- The operating systems simulate concurrency on a single CPU by interleaving the execution of different tasks
- Application-based solutions
- the application software takes responsibility for
switching between different branches of code at appropriate times
- the application software takes responsibility for
Identify Process and Thread:
- Provides heavyweight flow of control
- Is stand-alone
- Can be divided into individual threads
- Provides lightweight flow of control
- Runs in the context of an enclosing process
- Processes can be modeled using
- Active classes (Class Diagrams) and Objects (Interaction Diagrams)
- Components (Component Diagrams)
- Stereotypes: <<process>> or <<thread>>
- Process relationships can be modeled as dependencies
- Process creation takes place when the application starts
- Process destruction takes place when the application ends
- New processes are typically created from the initial process that was created when the application was started
- Each process must be individually destroyed
Step 14: Design Elements-to-Processes Considerations
- Based on:
- Performance and concurrency requirements
- Distribution requirements and support for parallel execution
- Redundancy and availability requirements
- Class/subsystem characteristics to consider:
Draw process diagram.
For complete solution: contact firstname.lastname@example.org