TABLE OF CONTENTS In this chapter, we will first consider some common misconceptions relating to models and model-based design. Once we have dispelled these misconceptions, we shall delve deeper into agile modelling. We will consider the attributes of agile models as well as what agile models look like and when they should be updated.
Before discussing Agile Modelling, it is worth reconsidering some modelling myths and misconceptions that need to be clarified. These have a bearing on Agile Modelling as a modelling misconception can lead to a denial of the benefits that can be accrued from Agile Modelling.
Models equal documentation.
Nothing could be further from the truth! A model is part of the documentation, but it is by no means sufficient as documentation. That is, a (UML) model, as good as it may be, cannot adequately represent all the information needed to describe how the requirements (functional and nonfunctional), behavioural and structural of a software system are to be implemented. For example, Figure 3.1 illustrates part of a Rose model developed for a real-world system built on one of the projects I have worked on. This Rose model has links to word documents (such as Overview), screen designs (such as APS-Frame-View), design notes ( APS-MVC-Design), classes ( APSFrameController, APSFrameModel, APSFrameView), Sequence diagrams (View SQM Questions) as well as class diagrams, collaboration diagrams, Visio diagrams (in pseudo UML as well as Screen layout designs indicating panels, layouts and components), Activity diagrams, etc.
