Software Systems Analysis: Data Representation, Behavior Modeling, and Trends, Exams of Logic

Download Software Systems Analysis: Data Representation, Behavior Modeling, and Trends and more Exams Logic in PDF only on Docsity! Software Systems Analysis— A Research Area Overview Reema Al-Kamha Abstract Software systems analysis is a field in which analysts continually learn new tech- niques and approaches to properly capture, maintain, understand, and develop more efficient and effective software systems. We begin this research area overview by defin- ing systems, systems analysis, and modeling. In subsequent sections, we focus on data and behavior representation of the system under study, prototyping, and formalism. Finally, we introduce some of the current work such as form-oriented analysis, fisheye views to support system analysis, and extreme programming and consider future work on software systems analysis such as extreme non-programming and new challenges for conceptual modeling. 1 Introduction By way of introduction, it is important to define software systems, systems analysis, and modeling. 1.1 Systems Several authors have defined a software system: “a system is an assemblage of parts forming a complex or unitary whole that serves a useful purpose” [BF90], “a system is a group of interacting objects” [EKW92], and “a system is a set or arrangement of elements that are organized to accomplish some predefined goal by processing information” [Pre01]. From these definitions we draw our definition of a software system as a set of interacting software components that serve a useful purpose. The components themselves may be considered to be software systems; with respect to large systems they are considered to be subsystems. 1.2 Systems Analysis Systems analysis is the study of a system under consideration (which may be real or imag- ined) [EKW92]. Its purpose is understanding and documentation of the essential charac- 1 teristics of the system being studied. Its eventual goal is to come up with a specification of the system under study. 1.3 Modeling A model provides the blueprints of a system [BRJ99]. A good model includes all the effec- tive components in the system under study and ignores all elements that are not relevant. Modeling provides a better understanding and visualization of the system under study. Every system can be described from different aspects using different models. A model may emphasize components and their relationship to other components in the system un- der study, the behavior of each component in the system or the interactions among the components in the system under study. 2 Representation—Data During analysis, analysts represent the data of the system under study in terms of metadata concepts and relationships. Metadata helps the analysts focus more easily on matching the data representation to the requirements of the system under study. We consider three representations of data that are commonly used in systems analysis: conceptual data modeling, knowledge representation, and ontologies. 2.1 Conceptual Data Modeling In software systems analysis, conceptual data models have proven to be quite successful for representing data at a higher level of abstraction. Conceptual models represent components and their relationship to other components in the system under study in a graphical way at a conceptual level. Some of the well known conceptual models are ER [Che76], ORM [Hal01], ORM [EKW92], and UML [BRJ99]. (Note that “ORM” in [Hal01] is Object-Role Modeling and is pronounced “orm”, while “ORM” in [EKW92] is Object-Relationship Model and is pronounced “O”-“R”-“M”.) • Entity Relationship Model [Che76]: ER models were introduced by Chen in his classic 1976 article to represent the conceptual structure of data in a database system. The ER modeling constructs are entities, attributes, and relationships among the entities. In ER diagrams (ERD’s) entities are represented as rectangles, relationships among entities are represented as diamonds connected by lines to entities, and attributes are represented by ovals hanging off lines attached to entities. Later modifications to classic ERD’s include ISA and CONTAINED-IN relationships [TYF86]. 2 developed with Ontolingua is typically defined by: relations, classes (treated as unary relations), functions (defined like a relation), individuals (distinguished objects), and axioms (relating these terms). • CYC [LG90]: CYC provides a foundation for common sense reasoning by developing ontologies for a wide variety of domain-specific applications. Knowledge in CYC is represented in the form of assertions in a variant of first-order-logic called CYCL. The CYC knowledge base itself contains simple assertions, interface rules, and control rules for its interface; an interface engine can be used to drive new assertions using this knowledge base. • Web Ontology Language (OWL) [HPSH03]: OWL is a standard ontology language for the web and an interchange format for ontologies. It unifies three useful aspects for on- tologies: knowledge modeling primitives provided by frame systems; formal semantics and efficient reasoning support from description logics; and a syntax compatible with the Web standard. It provides three sub-languages that meet different users’ needs: (1) OWL-Lite can provide a class hierarchy together with some simple constraints, (2) OWL-DL is based on description logic formalisms which allow for powerful logic expressions, and (3) OWL Full enables maximum expressiveness, without regard for computational limits. OWL is an extension of RDF and RDF Schema. There is no strict line between ontologies and conceptual data models, but ontologies are typically more general and more reusable; are intended for multiple purposes, goals, and users; are more easily shareable; and take a stronger stand on semantics of concepts. 3 Representation—Behavior An important goal of analysis is to capture and communicate not only the static aspects of a system under study, but also its dynamic behavior. Behavior may be the behavior of each component in the system or interactions among the components in the system under study. There are several behavior models commonly used to describe the behavior of the system under study including Petri nets [Pet77], finite-state machines [Cho78], statecharts [Har87], and state nets [EKW92]. • Petri Nets (PNs): Petri nets were first introduced in 1962 by C.A. Petri and were described well by Peterson [Pet77]. A Petri net model has two types of nodes: places and transitions. 5 Places can contain tokens which are used to simulate the dynamic and concurrent activities of systems. Once tokens are assigned to places, the resulting Petri net is said to be marked. A transition is enabled if each of its input places contains at least one token. Only enabled transitions can fire, and when a transition fires it consumes a token from each input place and produces a token for each output place. There are three kinds of arcs in petri net graphs: input arcs, output arcs, and inhibitor arcs. Input arcs are arrow-headed arcs from places to transitions; output arcs are arrow-headed arcs from transitions to places, and inhibitor arcs are circle-headed arcs from places to transitions. In Petri-net modeling, places can represent conditions, and transitions can represent events. A token arriving at a place can be interpreted as a true condition. Petri nets have gained popularity in recent years because of their usefulness in model- ing and analyzing concurrent systems. However, the concept of time is not explicitly provided in Petri nets, which limits their usefulness for real-time systems. • Finite State Machines (FSM) [Cho78]: Finite state machines (FSM) are used in many reactive systems to describe the dynamic behavior of an object based on its state. Early on [Cho78] suggested using finite-state models to design and test small software components. Finite state machines can be represented as graphs where states are represented by circles and arcs are labeled with an event and an (optional) output event. A transition occurs if the system is in the state at the beginning of the arrow and the event on the transition occurs. The action is executed, and afterwards the system is in the state at the end of the arrow. Finite state machines cannot model concurrent systems. • Statecharts [Har87]: Statecharts extend traditional FSMs to include hierarchy, syn- chronized concurrency, and global communication. Statecharts consist of states, tran- sitions, and actions. A transition has a trigger. The triggers of the transitions are all events of two types: external events that come from external sources and internal events that come from internal sources. The trigger of a transition may also include a condition. A transition can be labeled not only with a trigger that causes it to be taken, but also, optionally with an action separated from the trigger by a slash. When the transition is taken, the specified action is carried out instantaneously. • State Nets [EKW92]: State nets are used to model the behavior of object instances of an object class. Every object set has a state net that documents states, tran- sition conditions, and actions for that object set. The state net consists of states 6 and transitions. Transitions are represented as rectangular boxes with a horizontal dividing line. The upper part of a transition box contains its trigger. A trigger gives the condition that, when met, may cause the transition to fire. The lower part of a transition box contains its action, if any. Actions are operations that take place when the transition fires. Arrows (directed arcs) connect one or more states to a sin- gle transition. Arrows may have single-heads/single-tails, single-heads/multiple-tails, or multiple-heads/single-tails. Arrows that point to transitions are called in-arrows, while arrows that point away from transitions are called out-arrows. An in-arrow always has a single head. An out-arrow always has a single tail. State nets can have both inter-object concurrency and intra-object concurrency. Inter-object concurrency happens when several objects are in various states and transitions at the same time. Intra-object concurrency happens when an object instance is in more than one state or transition of a single copy of a state at any point in time. 4 Prototyping Prototyping is the technique of constructing a partial implementation of a system so that customers, users, or developers can learn more about a problem or a solution to that problem [Dav92]. It is a partial implementation because if it were a full implementation, it would be the system, not a prototype of it. There are at least two types of prototyping—throwaway and evolutionary. • In the throwaway approach, the prototype software is constructed in order to learn about the problem or its solution and is usually discarded after the desired knowledge is gained. • In the evolutionary approach, the prototype is constructed in order to learn more about the problem or its solution. Once the prototype has been used and the required knowledge gained, the prototype is then adapted to satisfy the new better understood needs. The prototype is then used again, more is learned, and the prototype is re- adapted. This process repeats indefinitely until the prototype system satisfies all needs and has thus evolved into the real system. Exemplary descriptions of prototyping include [BBC91, Hab91, JEW95]. 5 Formalism Formal methods are mathematically based techniques for describing system properties. Formalization can lead to models that are: (1) consistent such that no contradiction remains 7 6.2 Using Fisheye Views to Support Systems Analysis A recent technique introduced in [TSSO04] uses fisheye views as an aid to systems analysis and design. The idea is to make the conceptual models able to represent an entire system and a specific part of the system at the same time. The designer in this case can see a subprocess in the context of the entire system, while emphasizing a subprocesses of interest by enlarging the scale. The advantages of using fisheye views are to increase the effectiveness of system design due to the ability to recognize and eliminate redundancy and to effectively see linkages between subsystems. Actually, this is similar to high-level abstract views introduced more than decade ago in [EKW92]. High level abstractions reduce the complexity in large models. Their purpose is to represent fundamental system concepts, whereas lower level abstractions unfold sup- porting detail. Rather than using fisheye views, high-level constructs are shaded. When they are imploded, the shading shows that the designer can explode them to reveal more information. When they are exploded, the shading helps show the extent of the high-level construct. 6.3 Extreme Programming (XP) Although some people consider XP primarily as programming, it also includes the under- standing and documentation steps of systems analysis. XP was originated by Kent Beck [Bec00] as a new methodology for small-sized teams developing software with vague or rapidly changing requirements. XP techniques can be viewed as methods for rapidly build- ing and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, XP favors simple designs, metaphors, collaboration of users and programmers, frequent verbal communication, and feedback. In XP, the analyst and the developer are no longer separate; they are basically united in a single unit. In XP, progress during software development is measured and tracked based on the how well the code implements the observable behavior of the system. The code is the model. XP discourages documentation by making the requirement from the team only the code. When developing software systems with XP, the customer is asked to sit with the XP development team. Early on, the customer describes the system as a set of stories which are high-level statements of what the features of the system to be implemented should be. Stories are recorded on index cards. Developers estimate how long each story will take to implement. The customer decides, based on value and cost, the order in which stories will be developed. The team works iteratively: the customer writes tests and answers questions 10 while the programmers program. The XP customer has frequent opportunities to change the team’s direction if circumstances change. Because testing is so prominent, the customer is aware of the project’s true status much earlier. Some of the drawbacks of XP are: (1) it is designed for a single small team of fewer than a dozen team members; therefore it has problems scaling up for large projects; and (2) XP may not be applied to a system where planning ahead is necessary. 7 Summary and Future Directions In conclusion, software systems analysis has been here for a long time, and it covers a lot of things. We introduced some of its major aspects such as data and behavior representation of the system under study, prototyping, and formalism. In addition, we presented some of the recent work in that field. As we conclude, we mention some of the future directions in the field: extreme non-programming and new challenges for conceptual modeling. 7.1 Extreme Non-Programming (XNP) Tony Morgan in his keynote address at ISTA in July 2004, introduced the idea of extreme non-programming, which is a challenge in developing software systems. He motivated the change in the development process of software systems as follows: (1) the overall process of developing software has not changed much since the 1960s; (2) currently produced software is expensive, takes a long time to develop, and has low quality; and (3) most problems arise during analysis and specification in software development. In 80% of the cases the majority of problems can be traced back to the lack of a sufficient clear definition of project requirements. In extreme non-programming the process of developing software systems is the follow- ing: First the customers describe their needs to the analyst. The analyst translates the customers’ description into a model. Then the machine generates a human-readable view of that model which allows customers to clear up any misunderstandings before going fur- ther. A model can keep changing until the description is acceptable to the analyst and the customers. The next step is to automatically translate the model into code. In XNP, both the customers and the analyst share the same description of the problem; but they handle it in the way that is best suited for each. Potential benefits of applying extreme non-programming are: (1) fast development for a software system; and (2) improved software quality. 11 7.2 New Challenges for Conceptual Modeling Michael Carey in his ER2003 keynote address in Chicago issued a challenge to the con- ceptual modeling community to produce a simple conceptual model that (1) works well with XML and XML Schema; (2) abstracts well for conceptual entities and relationships; (3) scales to handle both large data sets and complex object interrelationships; (4) al- lows for queries and defined views via XQuery; and (5) accommodates heterogeneity. The conceptual model must work well with XML and XML Schema because XML is rapidly becoming the de facto standard for business data. Because conceptualizations must sup- port both high-level understanding and high-level program construction, the conceptual model must abstract well. Because many of today’s huge industrial conglomerations have large, enterprise-size data sets and increasingly complex constraints over their data, the conceptual model must scale up. Because XQuery, like XML, is rapidly becoming the industry standard, the conceptual model must smoothly incorporate both XQuery and XML. Finally, because we can no longer assume that all enterprise data is integrated, the conceptual model must accommodate heterogeneity. Accommodating heterogeneity also supports today’s rapid acquisitions and mergers, which require fast-paced solutions to data integration. References [BBC91] M. Baldassari, G. Brouno, and A. Castella. PROTOB: An object-oriented case tool for modeling and prototyping distributed systems. Software-Practice and Experience, 21(8):822–844, 1991. [BCM+03] F. Baader, D. Calvanese, D. McGuinness, D. Nardi, and P. Patel-Schneider. The Description Logic Handbook: Theory, Implementation and Applications. Cambridge University Press, Cambridge, Massachusetts, 2003. [Bec00] K. Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley, Reading, Massachusetts, 2000. [BF90] B. Blanchard and W. Fabrycky. Systems Engineering and Analysis. Prentice- Hall, Englewood Cliffs, New Jersey, 1990. [BRJ99] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, Reading, Massachusetts, 1999. [Bun77] M.A. Bunge. Treatise on Basic Philosophy: Vol. 3: Ontology I: The Furniture of the World. Reidel, Boston, Massachusetts, 1977. 12