Lucky Saxena

UML Notation

noreply@blogger.com (Ms.Lucky Saxena) — Wed, 20 Oct 2010 07:08:00 +0000

The elements of the UML notation
Things
Structural Things
Structural things are the nouns of UML models. These include classes, interfaces, collaborations,
use cases, active classes, components, and nodes.

Behavioral Things
Behavioral things are the dynamic parts of UML models. These include interactions and state
machines.

Grouping Things
Grouping things are the organizational parts of UML models. This includes packages.

Annotational Things
Annotational things are the explanatory parts of UML models. This includes notes.

Relationships:
Dependency
A dependency is a semantic relationship between two things in which a change to one thing (the
independent thing) may affect the semantics of the other thing (the dependent thing).

Association
An association is a structural relationship that describes a set of links; a link is a connection
among objects.

Generalization
Generalization is a specialization/generalization relationship in which objects of the specialized
element (the child) are substitutable for objects of the generalized element (the parent).

Extensibility
The UML provides three mechanisms for extending the language's syntax and semantics:
stereotypes (which represent new modeling elements), tagged values (which represent new
modeling attributes), and constraints (which represent new modeling semantics).

Software Development Life Cycle

noreply@blogger.com (Ms.Lucky Saxena) — Wed, 20 Oct 2010 06:46:00 +0000

The UML is largely process-independent, meaning that it is not tied to any particular software development life cycle. However, to get the most benefit from the UML, you should consider a process that is
· Use case driven
· Architecture-centric
· Iterative and incremental
Use case driven means that use cases are used as a primary artifact for establishing the desired behavior of the system, for verifying and validating the system's architecture, for testing, and for communicating among the stakeholders of the project.
Architecture-centric means that a system's architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development. An iterative process is one that involves managing a stream of executable releases. An is one that involves the continuous integration of the system's architecture to produce these releases, with each new release embodying incremental improvements over the other.
iterative and incremental process is risk-driven, meaning that each new release is focused on attacking and reducing the most significant risks to the success of the project.This use case driven, architecture-centric, and iterative/incremental process can be broken into phases. A phase is the span of time between two major milestones of the process, when a welldefined set of objectives are met, artifacts are completed, and decisions are made whether to move into the next phase.
There are four phases in the software development life cycle: inception, elaboration, construction, and transition.
In the diagram, work flows are plotted against these phases, showing their varying degrees of focus over time.

Inception is the first phase of the process, when the seed idea for the development is brought up to the point of being• at least internally• sufficiently well-founded to warrant entering into the elaboration phase.
Elaboration is the second phase of the process, when the product vision and its architecture are defined. In this phase, the system's requirements are articulated, prioritized, and baselined. A system's requirements may range from general vision statements to precise evaluation criteria, each specifying particular functional or nonfunctional behavior and each providing a basis for testing.
Construction is the third phase of the process, when the software is brought from an executable architectural baseline to being ready to be transitioned to the user community. Here also, the system's requirements and especially its evaluation criteria are constantly reexamined against the business needs of the project, and resources are allocated as appropriate to actively attack risks to the project.
Transition is the fourth phase of the process, when the software is turned into the hands of the user community. Rarely does the software development process end here, for even during this phase, the system is continuously improved, bugs are eradicated, and features that didn't make an earlier release are added.

Use-Case diagram and elements of Use-Case diagram

noreply@blogger.com (Ms.Lucky Saxena) — Fri, 15 Oct 2010 03:17:00 +0000

The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case. A use case diagram captures the functional aspects of a system. More specifically, it captures the business processes carried out in the system. Due to the simplicity of use case diagrams, and more importantly, because they are shorn of all technical jargon, use case diagrams are a great storyboard tool for user meetings. Use case diagrams have another important use. Use case diagrams define the requirements of the system being modeled and hence are used to write test scripts for the modeled system.
ELEMENTS OF USE CASE DIAGRAM

A use case diagram is quite simple in nature and depicts two types of elements: one representing the business roles and the other representing the business processes. Let us take a closer look at use at what elements constitute a use case diagram.

Actors: An actor portrays any entity (or entities) that performs certain roles in a given system. The different roles the actor represents are the actual business roles of users in a given system. An actor in a use case diagram interacts with a use case. For example, for modeling a banking application, a customer entity represents an actor in the application. Similarly, the person who provides service at the counter is also an actor. But it is up to you to consider what actors make an impact on the functionality that you want to model. If an entity does not affect a certain piece of functionality that you are modeling, it makes no sense to represent it as an actor. An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary.

UML Notation :

In the UML,an actor is represented by “stickman”.

An actor in a use case diagram

To identify an actor, search in the problem statement for business terms that portray roles in the system. For example, in the statement "patients visit the doctor in the clinic for medical tests," "doctor" and "patients" are the business roles and can be easily identified as actors in the system.

Use case: A use case in a use case diagram is a visual representation of a distinct business functionality in a system. Each of these business functions can be classified as a potential use case. Identifying use cases is a discovery rather than a creation. As business functionality becomes clearer, the underlying use cases become more easily evident. A use case is shown as an ellipse in a use case diagram.

UML Notation :

In the UML, a use case is represented by an oval .

Use cases in a use case diagram

A use case is a sequence of events (transactions) performed by a system in response to a trigger initiated by an actor. A use case contains all the events that can occur between an actor-use case pair, not necessarily the ones that will occur in any particular scenario. In its simplest form, a use case can be described as a specific way of using the system from a user’s (actor’s) perspective. A use case also illustrates:

1) A pattern of behavior the system exhibits.

2) A sequence of related transactions performed by an actor and the system.

Use cases provide a means to:

1) Capture system requirements.

2) Communicate with the end users and domain experts.

3) Test the system.

Use cases are best discovered by examining what the actor needs and defining what the actor will be able to do with the system; this helps ensure that the system will be what the user expects.

· Relationships: Use cases share different kinds of relationships. A relationship between two use cases is basically a dependency between the two use cases. Defining a relationship between two use cases is the decision of the modeler of the use case diagram. Use case relationships can be one of the following:

UML Notation :

In the UML, an relationship is represented by a solid line with or without an arrow.

· Flow of Events:
A flow of events is a sequence of transactions (or events) performed by the system.They typically contain very detailed information, written in terms of what the system should do, not how the system accomplishes the task.

A flow of events should include:

1) When and how the use case starts and ends

2) Use case/actor interactions

3) Data needed by the use case

4) Normal sequence of events for the use case

5) Alternate or exceptional flows