skip to main content
article
Free Access

Essential modeling: use cases for user interfaces

Authors Info & Claims
Published:01 April 1995Publication History
First page image

References

  1. 1 Constantine, L. L Compl~dty and creeping t'eaturism. Computer Long, rage Magazine 9, I0 (October 1992).Google ScholarGoogle Scholar
  2. 2 Constantine, L. L. Getting the User Inter~ce Rigl,u Basic Principles. Software Development '93 Cut.fence Proceedingx Miller Freeman, San Francisco, 1993.Google ScholarGoogle Scholar
  3. 3 Constantine, L. L. interfaces for intermediates. IEEE Software 11, 4 (July 1994): 96-99. Google ScholarGoogle Scholar
  4. 4 Constantine, L. L. Graphical navigation, Wittdows 7~ch Journal3, 8 (Augus~ 1994).Google ScholarGoogle Scholar
  5. 5 Comtaatine, L. L. "Persistent Usability: A Muhlphasic User Interface Architecture for Supporting the Full Usage Lifecycle," in S. Howard and Y. K. Leung, eds., OzCH194 Proceedings. Melbourne, November 1994.Google ScholarGoogle Scholar
  6. 6 Constantine, L. L. Essentially speaking. Software Development 2, 11 (November ! 994): 95-96.Google ScholarGoogle Scholar
  7. 7 Constantine, L L. Comtantine on Peopleware, Englcwood Cli~, NJ: Pzentice Hall, 1995.Google ScholarGoogle Scholar
  8. 8 Constantine, L { , and {.ncl,'xvnr~d, I_ A. ~_ I__ Essential Use Cases. Essential ModelitJgfor User linerface Design. Tutorial Notes, OzCHI 94, Melbourne, November 1994.Google ScholarGoogle Scholar
  9. 9 Holtzblatt, K., and Beyer, H. Making c,tswmer-centered design work for teams. Communications oftt~e ACM36, 10 (October 1993). Google ScholarGoogle Scholar
  10. 10 Jacobson, I., Chriszerson, M., Jonsson, P., and G~ver. gaard, G. Object-Oriented Software Engineering: A Use Case Ddven Approach. Addison-Wesle); Reading, Mass., t 992. Google ScholarGoogle Scholar
  11. 11 Jacobson, I., Ericsson, M., and Jacobson, A. Tl~e Object Advantage: Bminess Process Revngineering wM, Object 7kchnolog~ Addison-Wesle); Reading, Mass,, 1994. Google ScholarGoogle Scholar
  12. 12 McMenamin, S., and Palmer, J. Essential S3smn.~ Analysis. Prentice Hall, Englewood Cli~, N.J., 1984.Google ScholarGoogle Scholar
  13. 13 Nielsen, J. Usability Engineering. Boston: Academic Press, 1993. Google ScholarGoogle Scholar
  14. 14 Raskin, J. Intuitive equals familiar. Commtenlcations of the ACM37, 9 (,September 1994): 17-18. Google ScholarGoogle Scholar
  15. 15 S~evens, W. P., Myers, G.j., and Constantine, L L, 5~ructured design. IBM Systems Journal 13, 2 (May 1974).Google ScholarGoogle Scholar
  16. 16 Wirfs-Brock, R. Designing scenarios: making the :ase for a use case framework. Smalltalk Report, November-December 1993.Google ScholarGoogle Scholar

Index Terms

  1. Essential modeling: use cases for user interfaces

      Recommendations

      Reviews

      Thomas C. Lowe

      According to Kelly-Bootle, a word processor is “a text editor with 200 unused features” [1]. Constantine states a premise at the outset of this paper: Great graphics and sound ergonomics are wasted if a system is not really useful and usable…real usability…requires an architecture for the user interface and underlying functionality that fits with…the intent of users. Without insight into these essentials, developers [produce] software that fails to support users despite a veritable panoply of interface widgets and warts, dread symptoms of that modern software disease, creeping featuritis. The “essential use case modeling” approach is not a specific interface design technique, but a process to be used within design approaches based on users needs, in order to extend and qualify user-centered approaches. About half the paper is devoted to an example that provides clarity and motivation. Essential use case modeling is developed from two ideas. Essential modeling is concerned with the overall effect of a system, emphasizing the users work and objectives, rather than the means of achieving that effect. Use cases deal with what a system can do, that is, its essence as seen by a user on the outside. “SendingEmail” is an example of a use case. Individual use cases can have relationships: affinity (similarity), classification (subsets), extension (potentially reusable optional behaviors), and dependence. Since people use software in different capacities, the user role model is introduced to define specific circumstances. All this is coalesced and annotated in the use context model, which is the stage preceding the user interface architecture. It differs from the architecture in excluding appearance and details of components.

      Access critical reviews of Computing literature here

      Become a reviewer for Computing Reviews.

      Comments

      Login options

      Check if you have access through your login credentials or your institution to get full access on this article.

      Sign in

      Full Access

      • Published in

        cover image Interactions
        Interactions  Volume 2, Issue 2
        April 1995
        75 pages
        ISSN:1072-5520
        EISSN:1558-3449
        DOI:10.1145/205350
        Issue’s Table of Contents

        Copyright © 1995 ACM

        Publisher

        Association for Computing Machinery

        New York, NY, United States

        Publication History

        • Published: 1 April 1995

        Permissions

        Request permissions about this article.

        Request Permissions

        Check for updates

        Qualifiers

        • article

      PDF Format

      View or Download as a PDF file.

      PDF

      eReader

      View online with eReader.

      eReader