Figure 1 The initial class diagram of Music Program system
Related Figures (3)
Figure 2. The top-level OO-DFD of Music Programs system Figure 5. Interface design: The Menus tree within the transaction description that is identified as a “‘ba- sic” method or defined as an “application-specific” method of some class, is removed from the transaction’s description and replaced by a message to that class-method. But a pro- cedure/function that involves several classes, or performs some general computations, is not defined as an “ordinary” class method and is not attached to a specific class; rather, itremains within the transaction. The remaining parts of the transaction’s description are defined as “transaction method.” This method is actually the “main” part of the transaction’s program, and belongs to the Transactions class. Hence, when users ask the system (via proper menu selections) to perform some activity/transaction, they actually trigger the “main” method of the transaction; that method executes, and while executing it may call (send messages to) other methods (“basic” or “application-specific”) of respective classes, according to the process logic of the transaction. be too “formal;” it should include comments and explana- tions that will clarify the meaning of the transaction to the programmer who will implement it in the proper program- ming language. An equivalent way to describe a method is message chart (see example in Figure 7) which shows the classes, methods and messages included in a method, and the order/process logic of their execution. A message chart is actually an enhanced program flowchart which includes also the classes involved in the method and the messages to proper methods of those classes. As said, message charts are equivalent to pseudo-code and can be used interchange- ably. Figure 7. Message chart of the transaction stage, the programmers will use the above design products to create the software with any common OO programming language. the message charts. This has advantages and disadvantages: among the advantages are simplicity (of using any general- purpose tool) and flexibility (the possibility to adopt changes, if needed). The disadvantages are that a simple drawing tool does not provide for checking the syntactic correctness of the diagrams and for transformations from one product to the other. FUTURE DEVELOPMENTS In the future, we plan to develop a set of specialized CASE tools that will overcome the above limitations. More specifically, the set will include: a tool for drawing a
Connect with 287M+ leading minds in your field
Discover breakthrough research and expand your academic network
