A Use Case Model describes the proposed functionality of a new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. This interaction is a single unit of meaningful work, such as Create Account or View Account Details.

Each Use Case describes the functionality to be built in the proposed system, which can include another Use Case's functionality or extend another Use Case with its own behavior.

A Use Case description will generally includes:

* General comments and notes describing the use case.
* Requirements - The formal functional requirements of things that a Use Case must provide to the end user, such as <ability to update order>. These correspond to the functional specifications found in structured methodologies, and form a contract that the Use Case performs some action or provides some value to the system.
* Constraints - The formal rules and limitations a Use Case operates under, defining what can and cannot be done. These include:
o Pre-conditions that must have already occurred or be in place before the use case is run; for example, <create order> must precede <modify order>
o Post-conditions that must be true once the Use Case is complete; for example, <order is modified and consistent>
o Invariants that must always be true throughout the time the Use Case operates; for example, an order must always have a customer number.
* Scenarios – Formal, sequential descriptions of the steps taken to carry out the use case, or the flow of events that occur during a Use Case instance. These can include multiple scenarios, to cater for exceptional circumstances and alternative processing paths. These are usually created in text and correspond to a textual representation of the Sequence Diagram.
* Scenario diagrams - Sequence diagrams to depict the workflow; similar to Scenarios but graphically portrayed.
* Additional attributes, such as implementation phase, version number, complexity rating, stereotype and status.


For more visit :

http://www.sparxsystems.c om.au/resources/tutorial/use_c ase_model.html

Answered by Ashish Yadav , an ibibo Master, at 4:12 PM on September 11, 2008

Software Models

Class Models Class Model - Class diagrams are fundamental to object-oriented analysis and design. These diagrams show the static structure of object classes and important relationships between them. The Unified Modeling Language (UML) is the industry standard notation for class diagrams.

Process Model - Process models, also called data flow diagrams (DFDs) start with a top level context diagram for a system. The system is represented as a named process with data flows in and out to the external world. The most popular notations are Yourdon/DeMarco for technical software and Gane & Sarson for business systems.

The system process explodes to a child diagram where its split into smaller processes connected by flows and stores to illustrate data flow and transformation. Flows in and out of the system process must balance with flows in and out of its child diagram. This diagram leveling process continues until primitive processes yield a short textual description

Task Model - The Task window is used to create diagrams showing system architecture and task interactions in a multi-tasking environment. The UML Deployment diagram is a type of task diagram that shows the configuration of run-time processing elements.

Code - The Code or Browse window is used to view or edit code. Click to associated source code for a selected diagram object. Use the integrated Browse window to navigate through classes, attributes and operations in an object-oriented development project.

HTML - Popular web browsers like Netscape or Internet Explorer can be used to view HTML files linked to selected diagram objects. Scriptable HTML reports make your diagrams, specifications, requirements, dictionary and code or test files easily accessible to any web browser.

Data Model - An entity-relation diagram, called an ERD illustrates the data structure of an information system. A database can be designed using logical and physical data models that highlight primary and foreign keys. Martin's Information Engineering notation is typically used for data models.

State Model - The essential behavior of systems can often be expressed with a state model. State diagrams show events, states and actions in various notations including Mealy, Moore and UML/Harel.

States and events can also be shown in various kinds of tables including the Hatley/Pirbhai Process Activation Table, Decision Table, State Transition Matrix, State Transition Table, Shlaer/Mellor State Transition

Object Model - An object model shows object instances, their operations and messages between objects to document the mechanisms within an object-oriented design. Each diagram illustrates part of the design with a collection of communicating objects.

Popular notations include UML Sequence diagrams, UML Collaboration, Booch, Fusion and Shlaer/Mellor.

Answered by Sharad Singh , an ibibo Master, at 7:37 PM on September 09, 2008

Well , We use many models to design, develop, deploy, and manage technology solutions. A partial list of these models might include business cases, use case diagrams, entity relationship models, object models, code, test suites, deployment plans, logical data center models, and exception management plans. Software lifecycle methodologies have traditionally struggled to automate the production of "downstream" models from "upstream" models, or even to keep the different system models synchronized. This brief paper describes the modeling space and outlines current efforts to use models more effectively throughout the technology lifecycle. (4 printed pages)

Models are typically "scaled down" representations of real-world objects and systems. The reduction in scale may include size, detail, and aspect (a model that focuses on cost or durability while ignoring unrelated qualities of the system, for example). In the development of information technology solutions, models are used to manage complexity and to communicate system requirements between business stakeholders, solution and system architects, developers, and operations personnel.

Think about the many models used in engineering projects. Use-case models may be used to express the high-level functional requirements of the system and the roles that need to be supported. Risk models may define the prioritization of work by focusing on risk reduction as early as possible in the project timeline. Entity relationship models capture the basic information to be managed by the solution, and suggest appropriate factoring across tables, objects, and services. Logical system models form the basis of communication between development and operations. Prototypes permit early validation of requirements and solution strategies. The list goes on.

All of these models permit project participants to contribute their unique expertise to the development and management of the resulting system. All of these models help reduce both project cost and project risk by heading off misconceptions and oversights as early in the process as possible. Modeling tools and frameworks encourage the alignment of business and information technology groups by providing higher levels of traceability, visibility, and accountability across all levels of the solution design.

Microsoft is focused on making models more useful across the entire software lifecycle—from conception through development to operations and management. Historically, the only model that has maintained currency across the lifecycle has been the cryptic, detailed, and sadly incomplete model described by compilable code: the "source" of the system. Disharmony between system models causes frequent errors of perception and communication both within and across organizational disciplines, resulting in project and system failures.

Microsoft's goal is to permit all stakeholders—technical and non-technical, specialist and generalist—to have access to current, accurate, and appropriate representations of the organization's systems, expressed in languages with which each is familiar. Microsoft's intent is to empower all stakeholders—from the business analyst to the data architect to the security specialist to the network engineer—to contribute their expertise to the evolution of a solution, with a minimum of information loss.

For more details , Please visit the source site :

http://msdn.microsoft.com/en-u s/library/ms954611.aspx

Answered by Alok Gupta , an ibibo Guru, at 12:33 AM on September 06, 2008

A use case is a technique used in software and systems engineering to capture the functional requirements of a system. Use cases describe the interaction between a primary actor—the initiator of the interaction—and the system itself, represented as a sequence of simple steps. Actors are something or someone which exist outside the system under study, and who (or which) take part in a sequence of activities in a dialogue with the system, to achieve some goal: they may be end users, other systems, or hardware devices. Each use case is a complete series of events, from the point of view of the actor.[1]

According to Bittner and Spence:

“ Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful.[2] ”

Each use case describes how the actor will interact with the system to achieve a specific goal. One or more scenarios may be generated from each use case, corresponding to the detail of each possible way of achieving that goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by systems analysts and end users. The UML use case diagram can be used to graphically represent an overview of the use cases for a given system.

Within systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML requirement diagrams or similar mechanisms.

http://www.answ ers.com/topic/use-case

Answered by Nishu's , an ibibo Master, at 10:30 PM on September 05, 2008

hi,friend
The role of use-case modeling in software development
Use-case modeling is normally used in the early stages of system development. In so far as we can draw a distinction between analysis and design (and most practitioners of object-oriented development are reluctant to distinguish between them) it is a technique for system analysis and requirements analysis.

As an analysis tool, use-case modeling can be viewed in a number of different ways, but these views are complementary, not alternatives.

A tool for requirements elicitation

A use-case model shows the end-users of a system, other systems to which it is connected, and the services it provides. When used for requirements elicitation, use-case modeling is quite similar to the earlier concept of `structured viewpoint analysis'. In viewpoint analysis the first stage is to identify potential viewpoints in the system. A viewpoint is the way that the system is `seen' by its different users (bear in mind that some of the `users' may not be human, but other computer systems). Some experts suggest that identification of viewpoints requires at least a tentative identification of the services the system is to provide; the logic for this approach is that if there is a service it must have a user, and that user must have a viewpoint on the system. Kotonya and Sommerville's notion of a `service' is quite similar to a use-case. A later step in viewpoint analysis is to structure the viewpoints into a hierarchy. For example a bank may have private customers and business customers; both these groups of customers will `see' the bank's computer systems in a particular way. There will be considerable overlap between these views. For example, all customers will want to receive bank statements, withdraw and deposit funds, and query their account balances. But at the same time there will be some differences. For example, business customers will probably have different overdraft facilities

Answered by Nz , an ibibo Master, at 9:37 PM on September 05, 2008

Hello..

Use Case diagrams are formally included in two modeling languages defined by the OMG. Both the UML and SysML standards define a graphical notation for modeling use cases with diagrams. One complaint about the standards has been that they do not define a format for describing these use cases. Generally, both, graphical notation and descriptions are important as they are the documentation of the use case, showing the purposes an actor can use a system for.

Role of USE CASE

• The use case diagram shows the position or context of the use case among other use cases.
• As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team.

Answered by Saq , an ibibo Specialist, at 8:05 PM on September 05, 2008

Mr.007
A use case is a scenario that describes the use of a system by an actor to accomplish a specific goal. What does this mean? An actor is a user playing a role with respect to the system. Actors are generally people although other computer systems may be actors. A scenario is a sequence of steps that describe the interactions between an actor and the system. The use case model consists of the collection of all actors and all use cases. Use cases help us

capture the system's functional requirements from the users' perspective
actively involve users in the requirements-gathering process
provide the basis for identifying major classes and their relationships
serve as the foundation for developing system test cases

Answered by Keshto Patel , an ibibo Master, at 8:04 PM on September 05, 2008