Advertisement

Are Use Cases Necessarily the Best Start of an OO System Development Process?

  • Gerhard Skagestein

Abstract

Object-oriented modeling techniques may be used for modeling an automated information system, as well as for modeling the environment (the organization) using that system (D’Souza and Wills, 1999). You may even integrate the model of the system with the model of the environment. Where (and how) do you, however, draw the boundary between the environment and the computerised system? In a majority of the published models, the boundary is drawn through the message-symbols depicting the communication between objects in the environment and objects within the computerised system, implying that the interface of the system is identical with the aggregation of the interfaces of all the interface objects. This way of thinking is reinforced by the actor stereotype of UML (see for example (Eriksson and Penker, 1998) or (Jacobson, Booch, and Rumbaugh, 1999)), which implies the notion that some objects are definitely outside the systems, others inside. The paradigm has been inherited from the good old Dataflow context diagrams of the Structured Analysis and Design Methods (deMarco, 1978; Constantine and Yourdon, 1979) where a sole process in the middle serves the interests of the external entities connected by dataflows to that process.

Keywords

Power Consumption Computerise System Power Company Case Diagram Collaboration Model 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. Agostini, A., De Michelis, G., Grasso, M.A., and Patriarca, S. „Reengineering a Business Process with an Innovative Workflow Management system: a Case Study,“ COOCS’93-11/93/CA, USA.Google Scholar
  2. Brown, W.J., Malveau, R.C., McCormick III, H.W., and Mowbray, T.J. AntiPatterns. Wiley 1998.Google Scholar
  3. deMarco, T. Structured Analysis and System Specification, Yourdon Press/Prentice Hall 1978.Google Scholar
  4. D’Souza, D. and Wills, A.C. Objects, Components and Frameworks, The Catalysis Approach Addison-Wesley 1999.Google Scholar
  5. Constantine, L.L. and Yourdon, E. Structured Design, Prentice Hall 1979.MATHGoogle Scholar
  6. Eriksson, H.-E. and Penker, M. UML Toolkit, John Wiley 1998.Google Scholar
  7. Hammer, M. „Reengineering Work: Don’t Automate, Obliterate,“ Harvard Business Review, July-August 1990, pp. 104–112.Google Scholar
  8. Larman, C. Applying UML and Patterns. Prentice Hall 1998.Google Scholar
  9. Wirf-Brock, R., Wilkerson, B., and Wiener, L. Designing Object-Oriented Software, Prentice Hall 1990.Google Scholar

Copyright information

© Springer Science+Business Media New York 2001

Authors and Affiliations

  • Gerhard Skagestein
    • 1
    • 2
  1. 1.Department of InformaticsUniversity of OsloNorway
  2. 2.Department of Mathematical SciencesAgricultural University of NorwayNorway

Personalised recommendations