Computer-aided software engineering

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Example of a CASE tool.

Computer-aided software engineering (CASE) is the scientific application of a set of tools
and methods to a software system which is meant to result in high-quality, defect-free, and
maintainable software products.[1] It also refers to methods for the development of
information systems together with automated tools that can be used in the software
development process.[2]

Contents
• 1 Overview
• 2 History
• 3 Supporting software
○ 3.1 Tools
○ 3.2 Workbenches
○ 3.3 Environments
• 4 Applications
• 5 Risks and associated controls
• 6 See also
• 7 References
• 8 External links

[edit] Overview
The term "computer-aided software engineering" (CASE) can refer to the software used for
the automated development of systems software, i.e., computer code. The CASE functions
include analysis, design, and programming. CASE tools automate methods for designing,
documenting, and producing structured computer code in the desired programming language.
CASE software supports the software process activities such as requirement engineering,
design, program development and testing. Therefore, CASE tools include design editors, data
dictionaries, compilers, debuggers, system building tools, etc.
CASE also refers to the methods dedicated to an engineering discipline for the development
of information system using automated tools.
CASE is mainly used for the development of quality software which will perform effectively.
[edit] History
The ISDOS project at the University of Michigan initiated a great deal of interest in the
whole concept of using computer systems to help analysts in the very difficult process of
analysing requirements and developing systems. Several papers by Daniel Teichroew fired a
whole generation of enthusiasts with the potential of automated systems development. His
PSL/PSA tool was a CASE tool although it predated the term. His insights into the power of
meta-meta-models was inspiring, particularly to a former student, Dr. Hasan Sayani,
currently Professor, Program Director at University of Maryland University College.
Another major thread emerged as a logical extension to the DBMS directory. By extending
the range of meta-data held, the attributes of an application could be held within a dictionary
and used at runtime. This "active dictionary" became the precursor to the more modern
"model driven execution" (MDE) capability. However, the active dictionary did not provide a
graphical representation of any of the meta-data. It was the linking of the concept of a
dictionary holding analysts' meta-data, as derived from the use of an integrated set of
techniques, together with the graphical representation of such data that gave rise to the earlier
versions of I-CASE.
The term CASE was originally coined by software company Nastec Corporation of
Southfield, Michigan in 1982 with their original integrated graphics and text editor
GraphiText, which also was the first microcomputer-based system to use hyperlinks to cross-
reference text strings in documents—an early forerunner of today's web page link.
GraphiText's successor product, DesignAid, was the first microprocessor-based tool to
logically and semantically evaluate software and system design diagrams and build a data
dictionary.
Under the direction of Albert F. Case, Jr. vice president for product management and
consulting, and Vaughn Frick, director of product management, the DesignAid product suite
was expanded to support analysis of a wide range of structured analysis and design
methodologies, notably Ed Yourdon and Tom DeMarco, Chris Gane & Trish Sarson, Ward-
Mellor (real-time) SA/SD and Warnier-Orr (data driven).
The next entrant into the market was Excelerator from Index Technology in Cambridge,
Mass. While DesignAid ran on Convergent Technologies and later Burroughs Ngen
networked microcomputers, Index launched Excelerator on the IBM PC/AT platform. While,
at the time of launch, and for several years, the IBM platform did not support networking or a
centralized database as did the Convergent Technologies or Burroughs machines, the allure
of IBM was strong, and Excelerator came to prominence. Hot on the heels of Excelerator
were a rash of offerings from companies such as Knowledgeware (James Martin, Fran
Tarkenton and Don Addington), Texas Instrument's IEF and Accenture's FOUNDATION
toolset (METHOD/1, DESIGN/1, INSTALL/1, FCP).
CASE tools were at their peak in the early 1990s. At the time IBM had proposed AD/Cycle,
which was an alliance of software vendors centered around IBM's Software repository using
IBM DB2 in mainframe and OS/2:
The application development tools can be from several sources: from IBM, from
vendors, and from the customers themselves. IBM has entered into relationships with
 Bachman Information Systems, Index Technology Corporation, and Knowledgeware,
Inc. wherein selected products from these vendors will be marketed through an IBM
complementary marketing program to provide offerings that will help to achieve
complete life-cycle coverage.[3]
With the decline of the mainframe, AD/Cycle and the Big CASE tools died off, opening the
market for the mainstream CASE tools of today. Nearly all of the leaders of the CASE
market of the early 1990s ended up being purchased by Computer Associates, including IEW,
IEF, ADW, Cayenne, and Learmonth & Burchett Management Systems (LBMS).
[edit] Supporting software
Alfonso Fuggetta classified CASE into 3 categories:[4]
1. Tools support only specific tasks in the software process.
2. Workbenches support only one or a few activities.
3. Environments support (a large part of) the software process.
Workbenches and environments are generally built as collections of tools. Tools can
therefore be either stand alone products or components of workbenches and environments.
[edit] Tools
CASE tools are a class of software that automate many of the activities involved in various
life cycle phases. For example, when establishing the functional requirements of a proposed
application, prototyping tools can be used to develop graphic models of application screens to
assist end users to visualize how an application will look after development. Subsequently,
system designers can use automated design tools to transform the prototyped functional
requirements into detailed design documents. Programmers can then use automated code
generators to convert the design documents into code. Automated tools can be used
collectively, as mentioned, or individually. For example, prototyping tools could be used to
define application requirements that get passed to design technicians who convert the
requirements into detailed designs in a traditional manner using flowcharts and narrative
documents, without the assistance of automated design software.[5]
Existing CASE tools can be classified along 4 different dimensions:
1. Life-cycle support
2. Integration dimension
3. Construction dimension
4. Knowledge-based CASE dimension[6]
Let us take the meaning of these dimensions along with their examples one by one:
Life-Cycle Based CASE Tools
This dimension classifies CASE Tools on the basis of the activities they support in the
information systems life cycle. They can be classified as Upper or Lower CASE tools.
• Upper CASE Tools support strategic planning and construction of concept-level
products and ignore the design aspect. They support traditional diagrammatic
languages such as ER diagrams, Data flow diagram, Structure charts, Decision Trees,
Decision tables, etc.
• Lower CASE Tools concentrate on the back end activities of the software life cycle,
such as physical design, debugging, construction, testing, component integration,
maintenance, reengineering and reverse engineering.
Integration dimension
Three main CASE Integration dimensions have been proposed:[7]
1. CASE Framework
2. ICASE Tools
3. Integrated Project Support Environment(IPSE)
[edit] Workbenches
Workbenches integrate several CASE tools into one application to support specific software-
process activities. Hence they achieve:
• a homogeneous and consistent interface (presentation integration).
• easy invocation of tools and tool chains (control integration).
• access to a common data set managed in a centralized way (data integration).
CASE workbenches can be further classified into following 8 classes:[4]
1. Business planning and modeling
2. Analysis and design
3. User-interface development
4. Programming
5. Verification and validation
6. Maintenance and reverse engineering
7. Configuration management
8. Project management
[edit] Environments
An environment is a collection of CASE tools and workbenches that supports the software
process. CASE environments are classified based on the focus/basis of integration[4]
1. Toolkits
2. Language-centered
3. Integrated
4. Fourth generation
5. Process-centered
Toolkits
Toolkits are loosely integrated collections of products easily extended by aggregating
different tools and workbenches. Typically, the support provided by a toolkit is limited to
programming, configuration management and project management. And the toolkit itself is
environments extended from basic sets of operating system tools, for example, the Unix
Programmer's Work Bench and the VMS VAX Set. In addition, toolkits' loose integration
requires user to activate tools by explicit invocation or simple control mechanisms. The
resulting files are unstructured and could be in different format, therefore the access of file
from different tools may require explicit file format conversion. However, since the only
constraint for adding a new component is the formats of the files, toolkits can be easily and
incrementally extended.[4]
Language-centered
The environment itself is written in the programming language for which it was developed,
thus enabling users to reuse, customize and extend the environment. Integration of code in
different languages is a major issue for language-centered environments. Lack of process and
data integration is also a problem. The strengths of these environments include good level of
presentation and control integration. Interlisp, Smalltalk, Rational, and KEE are examples of
language-centered environments.[4]
Integrated
These environments achieve presentation integration by providing uniform, consistent, and
coherent tool and workbench interfaces. Data integration is achieved through the repository
concept: they have a specialized database managing all information produced and accessed in
the environment. Examples of integrated environment are IBM AD/Cycle and DEC
Cohesion.[4]
Fourth-generation
Fourth-generation environments were the first integrated environments. They are sets of tools
and workbenches supporting the development of a specific class of program: electronic data
processing and business-oriented applications. In general, they include programming tools,
simple configuration management tools, document handling facilities and, sometimes, a code
generator to produce code in lower level languages. Informix 4GL, and Focus fall into this
category.[4]
Process-centered
Environments in this category focus on process integration with other integration dimensions
as starting points. A process-centered environment operates by interpreting a process model
created by specialized tools. They usually consist of tools handling two functions:
• Process-model execution
• Process-model production
Examples are East, Enterprise II, Process Wise, Process Weaver, and Arcadia.[4]
[edit] Applications
All aspects of the software development life cycle can be supported by software tools, and so
the use of tools from across the spectrum can, arguably, be described as CASE; from project
management software through tools for business and functional analysis, system design, code
storage, compilers, translation tools, test software, and so on.
However, tools that are concerned with analysis and design, and with using design
information to create parts (or all) of the software product, are most frequently thought of as
CASE tools. CASE applied, for instance, to a database software product, might normally
involve:
• Modeling business / real-world processes and data flow
• Development of data models in the form of entity-relationship diagrams
• Development of process and function descriptions
[edit] Risks and associated controls
Common CASE risks and associated controls include:
• Inadequate standardization: Linking CASE tools from different vendors (design tool
from Company X, programming tool from Company Y) may be difficult if the
products do not use standardized code structures and data classifications. File formats
can be converted, but usually not economically. Controls include using tools from the
same vendor, or using tools based on standard protocols and insisting on
demonstrated compatibility. Additionally, if organizations obtain tools for only a
 portion of the development process, they should consider acquiring them from a
vendor that has a full line of products to ensure future compatibility if they add more
tools.[5]
• Unrealistic expectations: Organizations often implement CASE technologies to
reduce development costs. Implementing CASE strategies usually involves high start-
up costs. Generally, management must be willing to accept a long-term payback
period. Controls include requiring senior managers to define their purpose and
strategies for implementing CASE technologies.[5]
• Slow implementation: Implementing CASE technologies can involve a significant
change from traditional development environments. Typically, organizations should
not use CASE tools the first time on critical projects or projects with short deadlines
because of the lengthy training process. Additionally, organizations should consider
using the tools on smaller, less complex projects and gradually implementing the tools
to allow more training time.[5]
• Weak repository controls: Failure to adequately control access to CASE repositories
may result in security breaches or damage to the work documents, system designs, or
code modules stored in the repository. Controls include protecting the repositories
with appropriate access, version, and backup controls.[5]
[edit] See also
• Data modeling
• Domain-specific modeling
• GForge Advanced Server
• LibreSource
• Method engineering
• Model-driven architecture
• Modeling language
• Rapid application development
[edit] References
1. ^ Kuhn, D.L (1989). "Selecting and effectively using a computer aided software
engineering tool". Annual Westinghouse computer symposium; 6–7 Nov 1989;
Pittsburgh, PA (U.S.); DOE Project.
2. ^ P. Loucopoulos and V. Karakostas (1995). System Requirements Engineering.
McGraw-Hill.
3. ^ "AD/Cycle strategy and architecture", IBM Systems Journal, Vol 29, NO 2, 1990;
p. 172.
4. ^ a b c d e f g h Alfonso Fuggetta (December 1993). "A classification of CASE
technology". Computer 26 (12): 25–38. doi:10.1109/2.247645.
http://www2.computer.org/portal/web/csdl/abs/mags/co/1993/12/rz025abs.htm.
Retrieved 2009-03-14.
5. ^ a b c d e Software Development Techniques. In: FFIEC InfoBase. Retrieved 26 Oct
2008.
6. ^ Software Engineering: Tools, Principles and Techniques by Sangeeta Sabharwal,
Umesh Publications
 7. ^ Evans R. Rock. Case Analyst Workbenches: A Detailed Product Evaluation.
Volume 1, pp. 229–242 by
[edit] External links
• CASE Tools A CASE tools' community with comments, tags, forums, articles,
reviews, etc.
• CASE tool index - A comprehensive list of CASE tools
• UML CASE tools - A comprehensive list of UML CASE tools. Mainly have
resources to choose a UML CASE tool and some related to MDA CASE Tools.
Retrieved from "http://en.wikipedia.org/wiki/Computer-aided_software_engineering"
Categories: Computer-aided software engineering tools | Software development | Data
management
Personal tools
• Log in / create account
Namespaces
• Article
• Discussion
Variants
Views
• Read
• Edit
• View history
Actions
Search
Top of Form

Bottom of Form
Navigation
• Main page
• Contents
• Featured content
• Current events
• Random article
• Donate to Wikipedia
Interaction
• Help
• About Wikipedia
• Community portal
• Recent changes
• Contact Wikipedia
Toolbox
 • What links here
• Related changes
• Upload file
• Special pages
• Permanent link
• Cite this page
Print/export
• Create a book
• Download as PDF
• Printable version
Languages
• Bosanski
• Català
• Česky
• Deutsch
• Español
• Français
• Italiano
• Lietuvių
• Nederlands
• 日本語
• Polski
• Português
• Русский
• ไทย
• 中文
• This page was last modified on 29 March 2011 at 23:34.
• Text is available under the Creative Commons Attribution-ShareAlike License;
additional terms may apply. See Terms of Use for details.
Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit
organization.
• Contact us
• Privacy policy
• About Wikipedia
• Disclaimers
•

•
Use case
From Wikipedia, the free encyclopedia
A use case in software engineering and systems engineering is a description of steps or
actions between a user (or "actor") and a software system which lead the user towards
something useful.[1] The user or actor might be a person or something more abstract, such as
an external software system or manual process.
Use cases are a software modeling technique that helps developers determine which features
to implement and how to gracefully resolve errors.[2]
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.
(Note that the "use" in "use case" is pronounced as the English noun /ˈjuːs/, not the English
verb /ˈjuːz/. Rephrased: this is a case of its use, not a case of using it.)

Contents
• 1 History
• 2 Use cases and the development process
• 3 Use case focus
• 4 Degree of detail
• 5 Actors
• 6 Business vs. System Use Cases
• 7 Use case notation
• 8 Limitations
• 9 See also
• 10 References
• 11 Further reading
• 12 External links

[edit] History
In 1986 Ivar Jacobson, later an important contributor to both the Unified Modeling Language
(UML) and the Rational Unified Process (RUP), first formulated the textual, structural and
visual modeling techniques for specifying use cases. The use case technique became popular
through Jacobson's 1992 book Object-Oriented Software Engineering - A Use Case Driven
Approach, co-authored with Magnus Christerson, Patrik Jonsson and Gunnar Övergaard.
Originally he used the terms usage scenarios and usage case, which were the more correct
translations of the Swedish word "användningsfall" he used, but found that neither of these
terms sounded natural in English, and eventually he settled on the term use case.[3] Since
Jacobson originated use case modeling many others have contributed to improving this
technique, including Kurt Bittner, Ian Spence, Alistair Cockburn, Gunnar Övergaard, Karin
Palmkvist, Patrik Jonsson, Magnus Christerson and Geri Schneider.
During the 1990s use cases became one of the most common practices for capturing
functional requirements. This is especially the case within the object-oriented community
where they originated, but their applicability is not restricted to object-oriented systems.
[edit] Use cases and the development process
The specific way use cases are used within the development process will depend on which
development methodology is being used. In certain development methodologies[which?], a brief
use case survey is all that is required. In other development methodologies[which?], use cases
evolve in complexity and change in character as the development process proceeds. Use cases
can be a valuable source of usage information and usage testing ideas. [4] In some
methodologies, they may begin as brief business use cases, evolve into more detailed system
use cases, and then eventually develop into highly detailed and exhaustive test cases.
[edit] Use case focus
"Each use case focuses on describing how to achieve a goal or a task. For most software
projects, this means that multiple, perhaps dozens of use cases are needed to define the scope
of the new system. The degree of formality of a particular software project and the stage of
the project will influence the level of detail required in each use case."[cite this quote]
Use cases should not be confused with the features of the system. One or more features (a.k.a.
"system requirements") describe the functionality needed to meet a stakeholder request or
user need (a.k.a. "user requirement"). Each feature can be analyzed into one or more use
cases, which detail cases where an actor uses the system. Each use case should be traceable to
its originating feature, which in turn should be traceable to its originating stakeholder/user
request.
Use cases treat the system as a black box, and the interactions with the system, including
system responses, are perceived as from outside the system. This is a deliberate policy,
because it forces the author to focus on what the system must do, not how it is to be done, and
avoids making assumptions about how the functionality will be accomplished.
A use case should:
• Describe what the system shall do for the actor to achieve a particular goal.
• Include no implementation-specific language.
• Be at the appropriate level of detail.
• Not include detail regarding user interfaces and screens. This is done in user-interface
design, which references the use case and its business rules.
[edit] Degree of detail
Alistair Cockburn, in Writing Effective Use Cases, identified three levels of detail in writing
use cases:[5]
• Brief use case -- consists of a few sentences summarizing the use case. It can be easily
inserted in a spreadsheet cell, and allows the other columns in the spreadsheet to
record priority, duration, a method of estimating duration, technical complexity,
release number, and so on.
• Casual use case -- consists of a few paragraphs of text, summarizing the use case.
• Fully dressed use case -- a formal document based on a detailed template with fields
for various sections; and it is the most common understanding of the meaning of a use
case. Fully dressed use cases are discussed in detail in the next section on use case
templates.
Some software development processes do not require anything more than a simple use case to
define requirements. However, some other development processes require detailed use cases
to define requirements. The larger and more complex the project, the more likely that it will
be necessary to use detailed use cases.
The level of detail in a use case often differs according to the progress of the project. The
initial use cases may be brief, but as the development process unfolds the use cases become
even more detailed. This reflects the different requirements of the use case. Initially they need
only be brief, because they are used to summarize the business requirement from the point of
view of users. However, later in the process, software developers need far more specific and
detailed guidance.
The Rational Unified Process invites developers to write a brief use case description in the
use case diagram, with a casual description as comments and a detailed description of the
flow of events in a textual analysis. All those can usually be input into the use case tool (e.g.,
a UML Tool, SysML Tool), or can be written separately in a text editor.
[edit] Actors
A use case defines the interactions between external actors and the system under
consideration to accomplish a goal. An actor specifies a role played by a person or thing
when interacting with the system.[6] The same person using the system may be represented as
different actors because they are playing different roles. For example, user "Joe" could be
playing the role of a Customer when using an Automated Teller Machine to withdraw cash,
or playing the role of a Bank Teller when using the system to restock the cash drawer.
[edit] Business vs. System Use Cases
Use cases may be described at the abstract level (business use case, sometimes called
essential use case), or at the system level (system use case). The differences between these is
the scope.
• A business use case is described in technology-free terminology which treats system
as a black box and describes the business process that is used by its business actors
(people or systems external to the process) to achieve their goals (e.g., manual
payment processing, expense report approval, manage corporate real estate). The
business use case will describe a process that provides value to the business actor, and
it describes what the process does. Business Process Mapping is another method for
this level of business description.
• A system use case describes a system that automates a business use case or process. It
is normally described at the system functionality level (for example, "create voucher")
and specifies the function or the service that the system provides for the actor. The
system use case details what the system will do in response to an actor's actions. For
this reason it is recommended that system use case specification begin with a verb
(e.g., create voucher, select payments, exclude payment, cancel voucher). An actor
can be a human user or another system/subsystem interacting with the system being
defined.
[edit] Use case notation
In Unified Modeling Language, the relationships between all (or a set of) the use cases and
actors are represented in a use case diagram or diagrams, originally based upon Ivar
Jacobson's Objectory notation. SysML, a UML profile, uses the same notation at the system
block level.
[edit] Limitations
Use cases have limitations:
 • Use case flows are not well suited to easily capturing non-interaction based
requirements of a system (such as algorithm or mathematical requirements) or non-
functional requirements (such as platform, performance, timing, or safety-critical
aspects). These are better specified declaratively elsewhere.
• Use case templates do not automatically ensure clarity. Clarity depends on the skill of
the writer(s).
• There is a learning curve involved in interpreting use cases correctly, for both end
users and developers. As there are no fully standard definitions of use cases, each
group must gradually evolve its own interpretation. Some of the relations, such as
extends, are ambiguous in interpretation and can be difficult for stakeholders to
understand.
• Proponents of Extreme Programming often consider use cases too needlessly
document-centric, preferring to use the simpler approach of a user story.
• Use case developers often find it difficult to determine the level of user interface (UI)
dependency to incorporate in a use case. While use case theory suggests that UI not be
reflected in use cases, it can be awkward to abstract out this aspect of design, as it
makes the use cases difficult to visualize. Within software engineering, this difficulty
is resolved by applying requirements traceability through the use of a traceability
matrix.
• Use cases can be over-emphasized. In Object Oriented Software Construction (2nd
edition), Bertrand Meyer discusses issues such as driving the system design too
literally from use cases and using use cases to the exclusion of other potentially
valuable requirements analysis techniques.
• Use cases have received some interest as a starting point for test design.[7] Some use
case literature, however, states that use case pre- and postconditions should apply to
all scenarios of a use case (i.e., to all possible paths through a use case) which is
limiting from a test design standpoint. If the postconditions of a use case are so
general as to be valid for all possible use case scenarios, they are likely not to be
useful as a basis for specifying expected behavior in test design. For example, the
outputs and final state of a failed attempt to withdraw cash from an ATM are not the
same as a successful withdrawal: if the postconditions reflect this, they too will differ;
if the postconditions don’t reflect this, then they can’t be used to specify the expected
behavior of tests. An alternative perspective on use case pre- and postconditions more
suitable for test design based on model-based specification is discussed in.[8]
• Some systems are better described in an information/data-driven approach than in a
the functionality-driven approach of use cases. A good example of this kind of system
is data-mining systems used for Business Intelligence. If you were to describe this
kind of system in a use case model, it would be quite small and uninteresting (there
are not many different functions here) but the set of data that the system handles may
nevertheless be large and rich in details.
[edit] See also
Software Testing portal

• Business case
• List of UML tools
• User story
 • Use case diagram
• Misuse case
[edit] References
1. ^ Bittner, Kurt & Spence, Ian (2003). Use case modeling. Addison-Wesley. p. xvi.
ISBN 9780201709131.
2. ^ Adolph, Steve et al. (2002). Patterns for effective use cases. Addison-Wesley. p. 2.
ISBN 9780201721843.
3. ^ Alistair Cockburn, "Use cases, ten years later"
4. ^ Gelperin, David. "Precise Use Cases". Retrieved 8 February 2011.
5. ^ A. Cockburn (2001). Writing Effective Use Cases. Boston, MA, USA: Addison-
Wesley Longman Publishing Co., Inc. ISBN 0-201-70225-8.
6. ^ http://www.omg.org/docs/formal/07-02-03.pdf §16.3.1
7. ^ Frank Armour and Granville Miller (2000). Advanced Use Case Modeling:
Software Systems. Addison-Wesley Professional. ISBN 0201615924.
8. ^ Richard Denney (2005). Succeeding with Use Cases: Working Smart to Deliver
Quality. Addison-Wesley Professional. ISBN 0321316436.
[edit] Further reading
• Jacobson I., Christerson M., Jonsson P., Övergaard G., Object-Oriented Software
Engineering - A Use Case Driven Approach, Addison-Wesley, 1992.
• Alexander I., Maiden N. Scenarios, Stories, Use Cases. Wiley 2004. ISBN
0470861940.
• Aurum A. Cox, K. and Jeffery. An experiment in inspecting the quality of usecase
descriptions. Journal of Research and Practice in Information Technology, 36(4):211–
229, 2004.
• Phalp K. Cox, K. and M. Shepperd. Comparing use-case writing guidelines. roc.
Workshop on Requirements Engineering: Foundation of Software Quality
(REFSQ’01), pages 101–112, 2001.
• Colom J.M. Ezpeleta, J. and J. Martinez. Comparing use-case writing guidelines. A
Petri net based deadlock prevention policy for flexible manufacturing systems,
11(2):173–184, 1995.
• E. B. Fernandez and J. C. Hawkins. Determining role rights from use cases. In RBAC
’97: Proceedings of the second ACM workshop on Role-based access control, pages
121–125, New York, NY, USA, 1997. ACM Press.
• R. Hurlbut. A survey of approaches for describing and formalizing use-cases.
Technical Report 97– 03, Department of Computer Science, Illinois Institute of
Technology, USA., 1997.
• Woo Jin Lee, Sung Deok Cha, and Yong Rae Kwon. Integration and analysis of use
cases using modular petri nets in requirements engineering. IEEE Trans. Softw. Eng.,
24(12):1115–1130, 1998.
• F. Torner, M. Ivarsson, F. Pettersson, and P. Ohman. Defects in automotive use cases.
In ISESE ’06: Proceedings of the 2006 ACM/IEEE international symposium on
International symposium on empirical software engineering, pages 115–123, New
York, NY, USA, 2006. ACM Presss.
[edit] External links
• Use Cases (Usability.gov)
• Basic Use Case Template by Alistair Cockburn
• "An Academic Survey on the Role of Use Cases in the UML"
Categories: Software project management | Software requirements | Unified Modeling
Language | SysML
• Log in / create account
• Article
• Discussion
• Read
• Edit
• View history
Top of Form

Bottom of Form
Navigation
• Main page
• Contents
• Featured content
• Current events
• Random article
• Donate to Wikipedia
Interaction
• Help
• About Wikipedia
• Community portal
• Recent changes
• Contact Wikipedia
Toolbox
• What links here
• Related changes
• Upload file
• Special pages
• Permanent link
• Cite this page
Print/export
• Create a book
• Download as PDF
 • Printable version
Languages
• Afrikaans
• Dansk
• Deutsch
• Español
• Français
• Italiano
• ‫עברית‬
• Nederlands
• Norsk (bokmål)
• 日本語
• Polski
• Português
• Русский
• Slovenčina
• Svenska
• Türkçe
• Tiếng Việt
• 中文
• This page was last modified on 5 April 2011 at 16:06.
• Text is available under the Creative Commons Attribution-ShareAlike License;
additional terms may apply. See Terms of Use for details.
Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit
organization.
• Contact us
• Privacy policy
• About Wikipedia
• Disclaimers
•