| | This Article | |
| |
| |
| | Share | |
| |
| |
| | Bibliographic References | |
| |
| |
| | Add to: | |
| |
Digg
Furl
Spurl
Blink
Simpy
Google
Del.icio.us
Y!MyWeb
| |
| | Search | |
| |
| |
| | |
Problem Oriented Software Engineering: Solving the Package Router Control Problem
March/April 2008 (vol. 34 no. 2)
pp. 226-241
Problem Orientation is gaining interest as a way of approaching the development of software intensive systems and yet a significant example that explores its use is missing from the literature. In this paper, we present the basic elements of Problem Oriented Software Engineering (POSE) which aims to bring both non-formal and formal aspects of software development together in a single framework. We provide an example of a detailed and systematic POSE development of a software problem, that of designing the controller for a package router. The problem is drawn from the literature, but the analysis presented here is new. The aim of the example is twofold: to illustrate the main aspects of POSE and how it supports software engineering design, and to demonstrate how a non-trivial problem can be dealt with by the approach.
[1] 226 W.M. Turski, “And No Philosophers' Stone, Either,” Information Processing, vol. 86, 1986.[2] J.G. Hall, L. Rapanotti, and M. Jackson, “Problem Oriented Software Engineering,” Technical Report 2006/10, Dept. of Computing, The Open Univ., 2006.[3] M.A. Jackson, Problem Frames: Analyzing and Structuring Software Development Problems, first ed. Addison-Wesley, 2001.[4] S.C. Kleene, Introduction to Metamathematics. Van Nostrand, 1964.[5] M.S. Feather, “Language Support for the Specification and Development of Composite Systems,” ACM Trans. Programming Languages and Systems, vol. 9, no. 2, pp. 198-234, Apr. 1987.[6] C. Morgan, Programming from Specifications, Int'l Series in Computer Science. Prentice Hall, 1994.[7] R.-J. Back and J. von Wright, “Trace Refinement of Action Systems,” Proc. Fifth Int'l Conf. Concurrency Theory, pp. 367-384, 1994.[8] D. Smith, “Comprehension by Derivation,” Proc. 13th Int'l Workshop Program Comprehension, pp. 3-9, May 2005.[9] S. Mellor, A. Clark, and T. Futagami, “Model-Driven Development,” IEEE Software, vol. 20, no. 5, pp. 14-18, Sept./Oct. 2003.[10] W. Swartout and R. Balzer, “On the Inevitable Intertwining of Specification and Implementation,” Comm. ACM, vol. 25, no. 7, pp.438-440, 1982.[11] R. Balzer, “Transformation Implementation: An Example,” IEEE Trans. Software Eng., vol. 7, no. 1, pp. 3-14, Jan. 1981.[12] D.S. Wile, “Program Developments: Formal Explanations of Implementations,” Comm. ACM, vol. 26, no. 11, pp. 902-911, Nov. 1983.[13] A. van Lamsweerde, “Goal-Oriented Requirements Engineering: A Guided Tour,” Proc. Fifth IEEE Int'l Symp. Requirements Eng., pp.249-263, Aug. 2001.[14] A. van Lamsweerde, A. Dardenne, B. Delcourt, and F. Dubisy, “The KAOS Project: Knowledge Acquisition in Automated Specification of Software,” Proc. AAAI Spring Symp. Series, pp.59-62, Mar. 1991.[15] E. Letier and A. van Lamsweerde, “Deriving Operational Software Specifications from System Goals,” ACM SIGSOFT Software Eng. Notes, vol. 27, no. 6, 2002.[16] A. van Lamsweerde, “From System Goals to Software Architecture,” Formal Methods for Software Architectures, M. Bernardo and P.Inverardi, eds., pp. 25-43, 2003.[17] R. Bloomfield, P. Bishop, C. Jones, and P. Froome, ASCAD: Adelard Safety Case Development Manual, 1998.[18] T. Kelly and R. Weaver, “The Goal Structuring Notation: A Safety Argument Notation,” Proc. Workshop Assurance Cases: Best Practices, Possible Obstacles, and Future Opportunities, 2004.[19] T.P. Kelly, “Arguing Safety: A Systematic Approach,” PhD dissertation, Dept. of Computing, Univ. of York, 1998.[20] S.E. Toulmin, The Uses of Argument. Cambridge Univ. Press, 1958.[21] E.A. Strunk and J.C. Knight, “The Essential Synthesis of Problem Frames and Assurance Cases,” Proc. Second Int'l Workshop Advances and Applications of Problem Frames, 2006.[22] G. Kiczales and M. Mezini, “Separation of Concerns with Procedures, Annotations, Advice and Pointcuts,” Proc. 19th European Conf. Object-Oriented Programming, 2005.[23] OMG, “Unified Modeling Language (UML) version 2.0,” http://www.omg.org/technology/documents/ formaluml.htm, 2007.[24] L. Rapanotti, J.G. Hall, and Z. Li, “Problem Reduction: A Systematic Technique for Deriving Specifications from Requirements,” IEE Proc.—Software, vol. 153, no. 5, pp. 183-198, 2006.[25] Z. Li, J.G. Hall, and L. Rapanotti, “From Requirements to Specification: A Formal Perspective,” Proc. Second ACM Int'l Workshop Advances and Applications of Problem Frames, 2006.[26] R. Seater and D. Jackson, “Problem Frame Transformations: Deriving Specifications from Requirements,” Proc. Second Int'l Workshop Advances and Applications of Problem Frames, 2006.[27] D. Lea, “Design Patterns for Avionics Control Systems,” Technical Report DSSA Adage Project ADAGE-OSW-94-01, State Univ. of New York, Nov. 1994.[28] G.E. Krasner and S.T. Pope, “A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80,” J. Object-Oriented Programming, vol. 1, no. 3, pp. 26-49, Aug. 1988.[29] P. Kruchten, The Rational Unified Process: An Introduction, second ed. Addison-Wesley, 2000.[30] C. Larman, Applying UML and Patterns, second ed. Prentice Hall, 2002.[31] M. Fowler, Patterns of Enterprise Application Architecture. Addison-Wesley Professional, 2002.[32] D. Mannering, J.G. Hall, and L. Rapanotti, “Towards Normal Design for Safety-Critical Systems,” Proc. 10th ETAPS Int'l Conf. Fundamental Approaches to Software Eng., pp. 398-411, 2007.[33] D. Mannering, J.G. Hall, and L. Rapanotti, “Safety Process Improvement with POSE and Alloy,” Proc. 26th Int'l Conf. Computer Safety, Reliability and Security, pp. 252-257, Sept. 2007.[34] D. Mannering, J.G. Hall, and L. Rapanotti, “Safety Process Improvement: Early Analysis and Justification,” Proc. Second IET Conf. System Safety, 2007.[35] D. Jackson, “Micromodels of Software: Lightweight Modelling and Analysis with Alloy,” Software Design Group, Laboratory for Computer Science, Massachusetts Inst. of Technology, http://alloy.mit.edureference-manual.pdf , 2001.[36] J.G. Hall, D. Mannering, and L. Rapanotti, “Arguing Safety with Problem Oriented Software Engineering,” Proc. 10th IEEE Int'l Symp. High-Assurance System Eng., 2007.[37] P. Zave and M.A. Jackson, “Four Dark Corners of Requirements Engineering,” ACM Trans. Software Eng. and Methodology, vol. 6, no. 1, pp. 1-30, 1997.[38] S. Owre, J. Rushby, and N. Shankar, “PVS: A Prototype Verification System,” Proc. 11th Int'l Conf. Automated Deduction, 1992.[39] A.P. Martin, P.H.B. Gardiner, and J.C.P. Woodcock, “A Tactical Calculus,” Formal Aspects of Computing, vol. 8, no. 4, pp. 479-489, 1996.
Index Terms:
Software Engineering, Requirements/Specifications, Methodologies
Citation:
Jon Hall, Lucia Rapanotti, Michael Jackson, "Problem Oriented Software Engineering: Solving the Package Router Control Problem," IEEE Transactions on Software Engineering, vol. 34, no. 2, pp. 226-241, Mar./Apr. 2008, doi:10.1109/TSE.2007.70769