Nothing Special   »   [go: up one dir, main page]

Skip to main content

Systematic Architectural Design Based on Problem Patterns

  • Chapter
  • First Online:
Relating Software Requirements and Architectures

Abstract

We present a method to derive systematically software architectures from problem descriptions. The problem descriptions are based on the artifacts that are set up when following Jackson's problem frame approach. They include a context diagram describing the overall problem situation and a set of problem diagrams that describe subproblems of the overall software development problem. The different subproblems should be instances of problem frames, which are patterns for simple software development problems. Starting from these pattern-based problem descriptions, we derive a software architecture in three steps. An initial architecture contains one component for each subproblem. In the second step, we apply different architectural and design patterns and introduce coordinator and facade components. In the final step, the components of the intermediate architecture are re-arranged to form a layered architecture, and interface and driver components are added. All artefacts are expressed as UML diagrams, using specific UML profiles. The method is tool-supported. Our tool supports developers in setting up the diagrams, and it checks different validation conditions concerning the semantic integrity and the coherence of the different diagrams. We illustrate the method by deriving an architecture for an automated teller machine.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Subscribe and save

Springer+ Basic
$34.99 /Month
  • Get 10 units per month
  • Download Article/Chapter or eBook
  • 1 Unit = 1 Article or 1 Chapter
  • Cancel anytime
Subscribe now

Buy Now

eBook
USD 15.99
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 109.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info
Hardcover Book
USD 109.99
Price excludes VAT (USA)
  • Durable hardcover edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Similar content being viewed by others

Notes

  1. 1.

    In the following, since we use UML tools to draw problem frame diagrams (see Figure 9.4), all requirement references will be represented by dashed lines with arrows and stereotypes ‹‹refersTo››, or ‹‹constrains›› when it is constraining reference.

  2. 2.

    The mentioned architectural styles are described in [11].

  3. 3.

    Alternatively, we could create several Customer classes, but these would have to have different names.

  4. 4.

    The technical context diagram is identical to the context diagram, because it is not necessary to describe new connection domains representing the platform or the operating system.

  5. 5.

    Our method does not rely on how these restrictions are represented. Possible representations are sequence diagrams, state machines, or grammars.

  6. 6.

    See the corresponding design pattern by Gamma et al. [16]: “Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystems easier to use.”

References

  1. Jackson M (2001) Problem Frames. Analyzing and structuring software development problems. Addison-Wesley, Boston

    Google Scholar 

  2. UML Revision Task Force (2009) OMG Unified Modeling Language: Superstructure, available at http://www.omg.org/spec/UML/2.2/Superstructure/PDF/, last checked: 2011-06-14

  3. Hatebur D, Heisel M (2009) Deriving software architectures from problem descriptions. In: Software Engineering 2009 – Workshopband pp 383–302 GI

    Google Scholar 

  4. Eclipse – An open development platform (2008) May 2008. http://www.eclipse.org/, last checked: 2011-06-14

  5. Eclipse Modeling Framework Project (EMF) (2008) May 2008. http://www.eclipse.org/modeling/emf/, last checked: 2011-06-14

  6. Papyrus UML Modelling Tool (2010) Jan 2010. http://www.papyrusuml.org, last checked: 2011-06-14

  7. Yu E (1997) Towards modelling and reasoning support for early-phase requirements engineering. In: Proceedings of the 3 rd IEEE Intern. Symposium on RE pp 226–235

    Google Scholar 

  8. Bresciani P, Perini A, Giorgini P, Giunchiglia F, Mylopoulos J (2004) Tropos: an agent oriented software development methodology. Auton Agents Multi-Agent Syst 8(3):203–236

    Article  Google Scholar 

  9. Bertrand P, Darimont R, Delor E, Massonet P, van Lamsweerde A (1998) GRAIL/KAOS: an environment for goal driven requirements engineering. In ICSE’98 – 20th International Conference on Software Engineering, New York

    Google Scholar 

  10. Bass L, Clements P, Kazman R (1998) Software architecture in practice. Addison-Wesley, Massachusets, first edition

    Google Scholar 

  11. Shaw M, Garlan D (1996) Software architecture. Perspectives on an emerging discipline. Prentice-Hall, Upper Saddle River

    MATH  Google Scholar 

  12. UML Revision Task Force (2009) OMG Unified Modeling Language: Infrastructure. available at http://www.omg.org/spec/OCL/2.0/, last checked: 2011-06-14

  13. SysML Partners (2005) Systems Modeling Language (SysML) Specification. see http://www.sysml.org, last checked: 2011-06-14

  14. Côté I, Hatebur D, Heisel M, Schmidt H, Wentzlaff I (2008) A systematic account of problem frames. In: Proceedings of the European conference on pattern languages of programs (EuroPLoP) Universitätsverlag Konstanz, pp 749–767

    Google Scholar 

  15. Choppy C, Hatebur D, Heisel M (2010) Systematic architectural design based on problem patterns (technical report). Universität Duisburg-Essen

    Google Scholar 

  16. Gamma E, Helm R, Johnson R, Vlissides J (1995) Design patterns – elements of reusable object-oriented Software. Addison Wesley, Reading, MA

    MATH  Google Scholar 

  17. UML4PF (2010) http://swe.uni-due.de/en/research/tool/index.php, last checked: 2011-06-14

  18. UML Revision Task Force (2006) OMG Object Constraint Language: Reference. http://www.omg.org/docs/formal/06-05-01.pdf

  19. Lencastre M, Botelho J, Clericuzzi P, Araújo J (2005) A meta-model for the problem frames approach. In: WiSME’05: 4th workshop in software modeling engineering

    Google Scholar 

  20. Hall JG, Rapanotti L, Jackson MA (2005) Problem frame semantics for software development. Softw Syst Model 4(2):189–198

    Article  Google Scholar 

  21. Seater R, Jackson D, Gheyi R (2007) Requirement progression in problem frames: deriving specifications from requirements. Requirements Eng 12(2):77–102

    Article  Google Scholar 

  22. Colombo P, del Bianco V, Lavazza L (2008) Towards the integration of SysML and problem frames. In: IWAAPF’08: Proceedings of the 3 rd international workshop on applications and advances of problem frames, New York, ACM, pp 1–8

    Google Scholar 

  23. Charfi A, Gamatié A, Honoré A, Dekeyser J-L, Abid M (2008) Validation de modèles dans un cadre d’IDM dédié à la conception de systèmes sur puce. In: 4èmes Journées sur l’Ingénierie Dirigée par les Modèles (IDM 08)

    Google Scholar 

  24. Choppy C, Heisel M (2003) Use of patterns in formal development: systematic transition from problems to architectural designs. In: recent trends in algebraic development techniques, 16th WADT, Selected Papers, LNCS 2755, Springer Verlag, pp 205–220

    Google Scholar 

  25. Choppy C, Heisel M (2004) Une approche à base de “patrons” pour la spécification et le développement de systèmes d’information. In: Proceedings approches formelles dans l’assistance au développement de Logiciels – AFADL’2004, pp 61–76

    Google Scholar 

  26. Choppy C, Hatebur D, Heisel M (2005) Architectural patterns for problem frames. IEE Proc Softw Spec Issue Relating Softw Requirements Architectures 152(4):198–208

    Google Scholar 

  27. Choppy C, Hatebur D, Heisel M (2006) Component composition through architectural patterns for problem frames. In: Proc. XIII Asia Pacific Software Engineering Conference (APSEC), IEEE, pp 27–34

    Google Scholar 

  28. Barroca L, Fiadeiro JL, Jackson M, Laney RC, Nuseibeh B (2004) Problem frames: a case for coordination. In: coordination models and languages, Proc. 6th international conference COORDINATION, pp 5–19

    Google Scholar 

  29. Lavazza L, Bianco VD (2006) Combining problem frames and UML in the description of software requirements. Fundamental approaches to software engineering. Lecture Notes in Computer Science 3922, Springer, pp 199–21

    Google Scholar 

  30. Lavazza L, Bianco VD (2008) Enhancing problem frames with scenarios and histories in UML-based software development. Expert Systems 25:28–53

    Article  Google Scholar 

  31. Hall JG, Rapanotti L, Jackson M (2008) Problem oriented software engineering. Solving package router control problem, IEEE Transactions on Software Engineering 34(2):226–241

    Google Scholar 

Download references

Acknowledgments

We would like to thank our anonymous reviewers for their careful reading and constructive comments.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Christine Choppy .

Editor information

Editors and Affiliations

Rights and permissions

Reprints and permissions

Copyright information

© 2011 Springer-Verlag Berlin Heidelberg

About this chapter

Cite this chapter

Choppy, C., Hatebur, D., Heisel, M. (2011). Systematic Architectural Design Based on Problem Patterns. In: Avgeriou, P., Grundy, J., Hall, J.G., Lago, P., Mistrík, I. (eds) Relating Software Requirements and Architectures. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-21001-3_9

Download citation

  • DOI: https://doi.org/10.1007/978-3-642-21001-3_9

  • Published:

  • Publisher Name: Springer, Berlin, Heidelberg

  • Print ISBN: 978-3-642-21000-6

  • Online ISBN: 978-3-642-21001-3

  • eBook Packages: Computer ScienceComputer Science (R0)

Publish with us

Policies and ethics