FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W100502016> ?p ?o ?g. }

• W100502016 endingPage "438" @default.
• W100502016 startingPage "434" @default.
• W100502016 abstract "Teaching software modeling and software design presents a different and difficult set of problems than teaching some of the other aspects of software such as testing and requirements. As we point out this is partly due to the inherent complexity of the concepts involved in software modeling and design that requires a different approach in teaching them. The science of software modeling and design is also not quite as fully developed and mature although some major progress have been made recently. The lack of a good collection of practical and yet small enough examples of modeling and design problems for classroom use for illustrating both the science part of modeling and design principles and the applications of those principles makes the teaching of these principles a significant challenge. We present a stepwise refinement approach for creating finite-state models that is better suited for classroom teaching. 1. Software Engineering Education A good Software Engineering training involves several key components. On the hand, we have team-work, software process (planning and management), and software evaluation (user-interface and performance); on the other hand, we have software requirements formulation, software modeling, software architecture, software design, software development and integration, and software (functional) testing. We focus here on the challenges faced in teaching software modeling and design. 2. Teaching Software Modeling and Design We can view the finite-state behavior modeling of a software as building a theory of how the software should appear to the user whereas the subsequent steps of software design and development may be viewed as the two engineering steps to actually create a software that behaves accordingly (i.e., driven by that theory). We view the class-hierarchy structure of a software, which shows the organization of the data items and the operations (functions) in the software, as its design part. A systematic method for creating an optimal classhierarchy the finite-state model and the userelationship between the data items and the functions is given in [3]. A semi-automatic tool to facilitate the creation of an optimal class-hierarchy an use-relationship is described in [4]. In [5], we showed that the finitestate model can also be used to group the functions of a software into components to create an architecture of the software before doing the class-hierarchy design. The success of both of these steps depends on building a correct finite-state model of the software. Although there is a systematic method for building a finite-state model a given (finite) list of valid action (event) sequences and a (finite) list of invalid sequences [1], this is not suitable for practical applications such as modeling a software because there is no way of knowing beforehand how many valid and invalid action sequences would be needed. Thus, the approach in [1] is suitable for building an approximate model, which can be heavily influenced by the list of valid and invalid sequences chosen. We remark that, in principle, should be able to analyze the requirements of a software to determine the valid and invalid action sequences but this can be very tedious for a large software. If the requirements do not support such an analysis then this means requirements are not specified properly and we need to redo them. Note that we cannot expect the requirements to give us a regular-expression [6] for a complete description of all valid action sequences, and thus choosing a set of valid and invalid sequences becomes essentially an step. For many applications, an extension of an invalid sequence is also invalid (i.e., once an error has occurred, it cannot be corrected by additional actions) and sometimes this can be useful in building a finite-state model. Our stepwise refinement approach is a practical method for building a finite-state model that alleviates the problems in [1] and that is suitable for classroom teaching. 2.1. Role of hierarchical information structure Learning involves organizing the facts (concepts), their relationships, and the rules (methods) for applying them in a way that makes the recall (search) the long-term memory during problem-solving easier [2]. In-depth learning means understanding not more facts and their relationships but also the constraints associated with each rule that determine when it is applicable. If the stored information in long-term memory is not easily searchable, then in a problem-solving session a student may not fail to recall the proper information but also recall some improper information and unsuccessfully try to apply it. The hierarchical information organization allow easier recall of relevant facts and rules during problem-solving. Thus, teachers need to structure the information presented to students in a hierarchical form whenever possible so that the students can organize (assimilate) the information more easily. 2.2. Generalization vs. compositional hierarchies The generalization and compositional hierarchies are the two main types of information hierarchies. We need different approaches to build them, and thus we require different approaches to deliver the information in these hierarchies to the students for their assimilation. They also require different approaches for the recall and use during a problem-solving session. In a generalization hierarchy, each item at level L + 1 is built by addition of a small chunk of new information to an item at level L. This incremental building of complex information structure is key to its success in teaching and learning. We can traverse a generalization hierarchy in a top-down fashion by any combination of depth-first and breadth-first methods as needed to fit the different learning styles [7]. For a compositional hierarchy, a breadth-first scheme in assimilating (and teaching) the information is more suitable. Here, a top-down approach applies to visual (global) learner and bottom-up approach to sequential (analytical) learner [7]. Note that the conceptual or logical design of a compositional hierarchy is done more easily in a top-down approach although the actual physical construction of the hierarchy may require a bottom-up approach. Indeed, there are cases where we need to combine the two types of hierarchies. The structure of a finite-state model falls in this category; see Fig. 1(i). Here, the threeway from-to relationship between transitions and states (which have two distinct roles from and to) is quite complex and involves a number of cardinality constraints as indicated in Fig. 1(iii). For example, the constraint 1:1 next to Transitions indicates that a given transition has a unique pair of from-state and to-state. The constraint 0:∞ at the other end of the link Transitions indicates that for a given pair of from-state and to-state there can be any number of transitions; the guards in transitions distinguish among these transitions. There are still other constraints such as only start-state, one or more final-states, every state is reachable the startstate, etc; the third constraint helps to keep the number of states small. These constraints are not captured in Fig. 1(iii). There are well-known algorithms [6] to simplify a finite-state model by deleting unreachable states and minimizing the number of states by merging equivalent states. Fig. 1(ii) shows a generalization hierarchy of different types of finite-state models, which does not include models involving time-constraints (timed-automata) and parallel operations (petri-nets)." @default.
• W100502016 created "2016-06-24" @default.
• W100502016 creator A5013803280 @default.
• W100502016 date "2008-01-01" @default.
• W100502016 modified "2023-09-23" @default.
• W100502016 title "Teaching Software Modeling and Design Based on The Science of Design and Science of Learning." @default.
• W100502016 cites W1965340047 @default.
• W100502016 cites W1989445634 @default.
• W100502016 cites W2122843710 @default.
• W100502016 cites W2331953749 @default.
• W100502016 hasPublicationYear "2008" @default.
• W100502016 type Work @default.
• W100502016 sameAs 100502016 @default.
• W100502016 citedByCount "0" @default.
• W100502016 crossrefType "journal-article" @default.
• W100502016 hasAuthorship W100502016A5013803280 @default.
• W100502016 hasConcept C115903868 @default.
• W100502016 hasConcept C127413603 @default.
• W100502016 hasConcept C145420912 @default.
• W100502016 hasConcept C15744967 @default.
• W100502016 hasConcept C199360897 @default.
• W100502016 hasConcept C2777904410 @default.
• W100502016 hasConcept C2780103759 @default.
• W100502016 hasConcept C37228920 @default.
• W100502016 hasConcept C41008148 @default.
• W100502016 hasConcept C44877443 @default.
• W100502016 hasConcept C52913732 @default.
• W100502016 hasConcept C529173508 @default.
• W100502016 hasConcept C539667460 @default.
• W100502016 hasConcept C55587333 @default.
• W100502016 hasConcept C56739046 @default.
• W100502016 hasConcept C96427005 @default.
• W100502016 hasConceptScore W100502016C115903868 @default.
• W100502016 hasConceptScore W100502016C127413603 @default.
• W100502016 hasConceptScore W100502016C145420912 @default.
• W100502016 hasConceptScore W100502016C15744967 @default.
• W100502016 hasConceptScore W100502016C199360897 @default.
• W100502016 hasConceptScore W100502016C2777904410 @default.
• W100502016 hasConceptScore W100502016C2780103759 @default.
• W100502016 hasConceptScore W100502016C37228920 @default.
• W100502016 hasConceptScore W100502016C41008148 @default.
• W100502016 hasConceptScore W100502016C44877443 @default.
• W100502016 hasConceptScore W100502016C52913732 @default.
• W100502016 hasConceptScore W100502016C529173508 @default.
• W100502016 hasConceptScore W100502016C539667460 @default.
• W100502016 hasConceptScore W100502016C55587333 @default.
• W100502016 hasConceptScore W100502016C56739046 @default.
• W100502016 hasConceptScore W100502016C96427005 @default.
• W100502016 hasOpenAccess W100502016 @default.
• W100502016 hasRelatedWork W114798035 @default.
• W100502016 hasRelatedWork W125378642 @default.
• W100502016 hasRelatedWork W130601223 @default.
• W100502016 hasRelatedWork W1538899008 @default.
• W100502016 hasRelatedWork W1584565827 @default.
• W100502016 hasRelatedWork W1855073618 @default.
• W100502016 hasRelatedWork W2001975547 @default.
• W100502016 hasRelatedWork W204035802 @default.
• W100502016 hasRelatedWork W2095786132 @default.
• W100502016 hasRelatedWork W2097920761 @default.
• W100502016 hasRelatedWork W2136728318 @default.
• W100502016 hasRelatedWork W2156396922 @default.
• W100502016 hasRelatedWork W2158665044 @default.
• W100502016 hasRelatedWork W2361983568 @default.
• W100502016 hasRelatedWork W2369746494 @default.
• W100502016 hasRelatedWork W2380003638 @default.
• W100502016 hasRelatedWork W2384295760 @default.
• W100502016 hasRelatedWork W35804719 @default.
• W100502016 hasRelatedWork W2106410314 @default.
• W100502016 hasRelatedWork W2147090024 @default.
• W100502016 isParatext "false" @default.
• W100502016 isRetracted "false" @default.
• W100502016 magId "100502016" @default.
• W100502016 workType "article" @default.