UML Faq's

Q - What is UML?

A - Unified Modeling Language (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. Using UML, programmers and application architects can make a blueprint of a project, which, in turn, makes the actual software development process easier.

Q - What can I use UML for?

A - UML was designed with these primary purposes in mind:

· Business process modeling with use cases

· Class and object modeling

· Component modeling

· Distribution and deployment modeling

Q - Do I really need UML? Can't I just describe how my application is designed using regular words?

A - While it's certainly possible to describe interrelated processes and code architecture in words, many people prefer to use a diagram to visualize the relationship of elements to one another. UML is a standard way to create these diagrams. As a result, it makes it easier for programmers and software architects to communicate.

Q – What are the difference types of diagrams available in UML?

A - UML provides many different models of a system. The following is a list of then:

1) The Use Case Diagrams - A use case is a description of the system's behavior from a user's viewpoint.

2) The Class Diagrams - "What objects do we need? How will they be related?"

3) Collaboration Diagrams - "How will the objects interact?"

4) Sequence Diagrams - "How will the objects interact?"

5) State Diagrams - "What state should our object be in"

6) Package Diagrams - "How are we going to modularize our development?"

7) Component Diagrams - "How will our software components be related?"

8) Deployment Diagrams - "How will the software be deployed?"

Q - Can you name the four phases of the Unified Process?
A -
Iterative, Incremental Frameworks is a logical extension to the spiral model, but is more formal and rigorous. The framework is divided into four major phases:

1) Inception: is concerned with establishing the scope of the project and generally defining a vision for the project.

2) Elaboration: The purpose of elaboration is to analyse the problem, develop the project plan further, and eliminate the riskier areas of the project.

3) Construction: At this phase we build the project. the project is build in same fashion as the spiral model, by following a series of iterations (simple waterfall).

4) Transition: The final phase is concerned with moving the final product accross to the customers.

Q - What is a "use case"?
A - A complete end-to-end business process that satisfies the needs of a user.

Q - What are different categories of use cases?
A - Detail Level: - High level / Expanded
Task Level: - Super / Sub (Abstract; Equal Alternatives; Complete v. Partial)
Importance: - Primary / Secondary (use Secondary for exceptional processes)
Abstraction: - Essential / Real

Q. What is the difference between a real and essential use case?
A. essential - describes the "essence" of the problem; technology independent real - good for GUI designing; shows problem as related to technology decisions.

Q - In a System Sequence Diagram, what is a System Event?
A - It is from the expanded use case. It is an actor action the system directly responds to.

Q. Give an example of a situation which a State Diagram could effectively model.
A - Think of a cake and its different stages through the baking process: dough, baked, burned.

Q - For what are Operations Contracts written?
A - System Events.

Q - In an Operations Contract's postconditions, four types of activities are specified. What are they?
A - They are:

· Instances created

· Associations formed

· Associations broken

· Attributes changed

Q - What does an Operations Contract do?
A. Provides a snapshot of the System's state before and after a System Event. It is not interested in the Event's specific behavior.

Q - What does a Collaboration Diagram (or Sequence Event, depending on the process) model?
A - A System Event's behavior.

Q - How does one model a class in a Collaboration Diagram? An instance?
A - A box will represent both; however, a class is written as MyClass whereas an instance is written as myInstance:MyClass.

Q - What are the three parts of a class in a Class Diagram?
A - Name, Attributes, Methods.

Q - In Analysis, we are interested in documenting concepts within the relevant problem domain. What is a concept?
A - A person, place, thing, or idea that relates to the problem domain. They are candidates for objects.

Q - Does a concept HAVE to become a class in Design?
A - No.

Q - In a Class Diagram, what does a line with an arrow from one class to another denote?
A - Attribute visibility.

Q - What are the four types of visibility between objects?
A - Local, parameter, attribute, global.

Q - When do you use inheritance as opposed to aggregation?
A - An aggregation is a "has a" relationship, and it is represented in the UML by a clear diamond. An example of an aggregate relation is Table of Contents and Chapter. A Table of Contents "has a" Chapter.

Q - When would I prefer to use composition rather than aggregation?
A - Composition is a stronger form of aggregation. The object which is "contained" in another object is expected to live and die with the object which "contains" it. Composition is represented in the UML by a darkened diamond. An example of a composite relation is a Book and Chapter. A Book "has a" Chapter, and the Chapter cannot exist without the Book.

Q - Is the UML a process, method, or notation?
A - It is a notation. A process is Objectory, Booch, OMT, or the Unified Process. A process and a notation together make an OO method.

Q - Can you tell us some good principles to use in OOA&D?
A - NOTE: This is not a complete list, by any means, but we have listed the GRASP Patterns here for examples (these help assign responsibilities between objects):

Low coupling
High cohesion
Don't Talk to Strangers
Pure Fabrication

Spiral Lifecycle Model

The spiral lifecycle model is the combination of the classic waterfall model and an element called risk analysis. This model is very appropriate for large software projects. The model consists of four main parts, or blocks, and the process is shown by a continuous loop going from the outside towards the inside. This shows the progress of the project.

  • Planning - This phase is where the objectives, alternatives, and constraints are determined.
  • Risk Analysis - What happens here is that alternative solutions and constraints are defined, and risks are identified and analyzed. If risk analysis indicates uncertainty in the requirements, the prototyping model might be used to assist the situation.
  • Engineering - Here the customer decides when the next phase of planning and risk analysis occurs. If it is determined that the risks are too high, the project can be terminated.
  • Customer Evaluation

The steps in the spiral model can be generalized as follows:

a) The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.

b) A preliminary design is created for the new system.

c) A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.

d) A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.

e) At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.

f) The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.

g) The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.

h) The final system is constructed, based on the refined prototype.

i) The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

No comments: