![]() ![]() ![]() ![]() If you think about the diagrams that appear, for example, in one of your textbooks, you don’t see page after page of diagrams without supporting text. Diagrams are a part of an overall documentation process. We create them to communicate with someone. We don’t create diagrams just for the sake of creating diagrams. The choice of perspective also depends on the context of the document in which it appears. Design model development will typically start with heavy emphasis on the specification perspective, and evolve into the implementation perspective. Analysis models will typically feature a mix of conceptual and specification perspectives. During the formulation of a domain model, for example, you would seldom move past the conceptual perspective. The choice of perspective depends on how far along you are in the development process. The perspective affects the amount of detail to be supplied and the kinds of relationships worth presenting. Implementation: describes how classes will implement their interfaces Specification: focus is on the interfaces of ADTs in the software. perhaps only loosely related to the software classes that will implement them.Conceptual: represents the concepts in the domain.Generalization (e.g., a Librarian is a specialized kind of Library Staff)Īssociation (e.g., a Patron may have up to 20 Publications checked out at one time)Ī diagram can be interpreted from various perspectives: The diagrams are actually the representation of a formal “language” and are expected to make statements that are meaningful according to the rules of that language.Ī class relationship diagram describes the types of objects in the system and selected static relationships among them. The success or failure of a diagram lies entirely in its ability to communicate what the author intended. If a diagram is too vague to convey any definite meaning, it has no more value than an equally vague sentence. If a diagram is too complicated to be understood, it’s no more use than a sentence that is too complicated to be understood. Instead, like the diagrams that appear in, say, your textbook, each one is intended as part of a larger document, much of which will be explanatory text.įurthermore, we draw diagrams for the same reasons we write sentences and paragraphs, to communicate some specific idea. We don’t usually draw diagrams to stand by themselves. The purpose of that strategy is communication. The diagrams are part of an overall documentation strategy. We’ll look eventually at the ones shown in italics, starting with class relationship diagrams. UML provides a number of different diagrams With applications outside of “traditional” software engineering: e.g., DBs UML notation has quickly become an industry standard Next we turn to more formal documentation that you can expect to show outside your team and probably to retain for the lifetime of the project. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |