(Institutional Affiliation) FORMAL REPORT COMPARING THE USE OF THE IDEF METHODOLOGY TO UML - Essay Example

? al Affiliation) FORMAL REPORT COMPARING THE USE OF THE IDEF METHODOLOGY TO UML IDEF and UML techniques have become very popular in academic and industrial circles (Kim 2003, pg. 1). IDEF is made up of a family of graphical modeling methods that are developed to formally define and communicate vital elements of enterprise engineering projects (Kim 2003, pg. 1). On the other hand, UML is a modeling language that is most suited to the generation of computer-executable platforms/frameworks that encode important elements of software engineering projects. This paper will seek to compare the use of IDEF to UML by focusing on their applications, nature, and techniques employed in their development. This comparison will be done on the basis of credible and reliable literatures, written and published by authorities on modeling languages and techniques. Key Words IDEF; UML; graphical modeling methods; enterprise engineering projects; modeling language The Approach/Rationale of both Methodologies a) IDEF According to Bernus, Mertins, & Schmidt (1998, pg. 17), the rationale for IDEF is to support modeling activities that are fundamental to system analysis, design, improvement or integration. b) UML The approach/rationale for UML is to act as the dominant, publicly accepted, and uniform objected oriented visual modeling language, and as a foundation object description language for the offshoot unified enterprise modeling language (UEML) that has been put forward by IFAC/IFIP (Bernus, Mertins, & Schmidt 1998, pg. 17). The Stages of the Systems Development Life Cycle that each Addresses IDEF methodology addresses documentation, design, integration, analysis, understanding, planning, and improvement (Fowler & Scott 2000, pg. 46). Based on the Waterfall model of the system development life cycle (SDLC), these functions fit into four stages of the SDLC: preliminary analysis, system analysis and requirements definition, systems design, integration and testing, and maintenance. On the other hand UML methodology is limited to the systems design phase. During the systems analysis phase, object-oriented analysis (OOA) is performed; its output is a conceptual model that is comprised of one (sometimes more) UML class diagram, a user-interface mock-up, a group of use cases, and a couple of interaction diagrams. This conceptual model is subsequently used as an input in objected-oriented design during the systems design phase (Lankhorst 2005, pg. 63). The Techniques used for modeling the Processes/Functions of the System (including the similarities and differences between the techniques and their strengths and weaknesses) a) IDEF Techniques IDEF is based on three modeling constructs/viewpoints/techniques which define its approach/rationale. These are: i) IDEF0 Function Modeling Method This method was created so as to represent processes or activities (consisting of partially sequenced groups of activities) that are usually executed in a systematic and uniform manner. IDEF0 defines a function as a group of activities that takes specific inputs and, using some mechanism, and based on certain controls, converts the inputs into outputs (Noran 2008, pg. 41). These ICOMs (inputs, controls, outputs and mechanisms) can be employed in the modeling of relationships between a wide range of activities (Kim 2003, pg. 3). IDEF0 modeling generally begins by defining a context diagram (Kim 2003, pg. 3). This is representative of the system’s overall purpose and its interactions with external environments (Kim 2003, pg. 3). Usually, IDEF0 models consist of a hierarchy of connected diagrams that are decomposed systematically hence encoding semantic data at lower modeling levels. The systematical breakdown brings not only detailed but also wide-scope representations of system or environmental activities (Bernus, Mertins, & Schmidt 1998, pg. 29). ii) IDEF1x Data Modeling Method This method was created to define data models that symbolize both the semantics and structure of data that is found in a target system or environment (Kim 2003, pg. 3). It is a notation that is an extension to the IDEF1 model and offers a semantic data modeling method that can support the design of conceptual schemas (S?erifi 2005, pg. 39). IDEF1x has similar modeling constructs and concepts to those normally found in E-R models (Kim 2003, pg. 3). It supports and enables official representation of attributes, entities, and relationships between entities (Kim 2003, pg. 3). IDEF1x models’ attributes can have just one owner. A vital perspective in IDEF1 x touches on the application of candidate keys. IDEF1 x modeling methods encode 3 types of relationships: non-specific relationships; specific connection relationships; and categorization relationships (Bernus, Mertins, & Schmidt 1998, pg. 30). iii) IDEF3 Process Modeling Method This method was designed to provide a means of symbolizing reachable states, timing, and sequence, and to define the time-based nature of systems. IDEF3 comprises two key sets of modeling mechanisms: process flow network (PFN) and object state transition network (OSTN) modeling constructs (S?erifi 2005, pg. 34). PFNs represent the conditions under which, and the sequence in which, a system performs activities. OSTN defines the transition periods that objects should go through when a specific process is being executed. b) UML Techniques UML is also based on three modeling constructs or viewpoints which define its approach/rationale. These are: i) Use Case Diagrams and Use Cases These state the generic processes that a system must deal with. They are composed of actors, use cases, and the system design type (Kim 2003, pg. 4). The use case defines a process that has to be performed with the help of the system, or the functionality the system offers. An actor does not form part of the system; an actor is a foreign element that should engage with the system. An actor is an instance; neither a class nor a type (Fowler & Scott 2000, pg. 41). Every actor symbolizes a role and not a single system user. Actors interact with the system by relaying and receiving messages, and a use case is triggered when they relay a message to the system. ii) Class Programs and Static Modeling “Class” is a descriptor that is employed in UML modeling to denote a group of objects with identical relationships, behavior, and data structure (Bernus, Mertins, & Schmidt 1998, pg. 52). Class diagrams can be employed to present a static perspective of a system with respect to the relationships among classes and their object classes (Kim 2003, pg. 4). In spite of this, class diagrams never encode data that is temporal. Static relationships in class diagrams are described by 4 types of UML modeling constructs (dependency, composition, association, and general). iii) Dynamic Modeling System objects generally need to interact with other system objects as well as objects that are foreign to that system (Kim 2003, pg. 4). In UML, object communications are defined using dynamic models. Altered system behavior is normally triggered when a message is sent from one object to another (S?erifi 2005, pg. 37). Modeling constructs are provided in UML to define the 4 kinds of message which are: simple, synchronous with immediate return, synchronous, and asynchronous (Kim 2003, pg. 4). In addition to this, UML offers modeling constructs to build 4 kinds of dynamic diagrams which are: activity diagrams, sequence diagrams, state diagrams, and collaboration diagrams (Kim 2003, pg. 4). Similarities and differences between the Techniques and their Strengths and Weaknesses Both IDEF and UML techniques can be used to model virtually any useful view of a system (Zhao 2010, pg. 6). IDEF techniques have around 30 years of development and a couple of US government bodies supporting it (e.g. the US Air Force, the Department of Defense, etc). Newer additions such as IDEF4 onwards address deal with new or modified requirements (Lankhorst 2005, pg. 16). On the other hand, UML techniques are fairly young when compared to IDEF, and are mostly directed at software development. UML can only be effectively used when backed by: a) Design patterns – these support propagation and reuse of design knowledge. b) Specific extensions – support effective capturing of business activities and processes. UML’s weakness is that despite the fact that it is composed of 9 different types of diagrams it still lacks a knowledge foundation and requires extensions. The many diagrams (two of which are purely focused on software deployment/development) originate from the manner in which UML was designed (methods unification) and do not seem to add much value when we leave the software design field (S?erifi 2005, pg. 30). On a positive note, UML techniques are easy to learn and can introduce interested individuals to advanced modeling methods like the meta-model. Users do not have use all the diagrams and have the freedom to implement their models as they wish. IDEF0 techniques separate organizations from functions, but do not detect time-ordered challenges between activities, nor enable the specification of a process. In addition to this, a balance must be realized between the level of abstraction expressed by the arrows (ICOMs) and that expressed by the boxes (Lankhorst 2005, pg. 26). IDEF0 does not also provide the conditions required to initiate or terminate a process. This is the reason why IDEF0 is best suited for combination with other IDEF techniques like IDEF3. IDEF 1 cannot be used directly in the implementation phase, but can be very useful in modeling data within an organization, free of implementation challenges (Zhao 2010, pg. 7). IDEF1x is a good technique for the foundation of database design, but does not abide by the standards of good graphical design (its symbols do not smoothly dovetail with the concepts they are required to model). Also, rectifying one mistake in a diagram relationship in IDEF1x usually initiates cascading changes. Overly cluttered and complex IDEF3 diagrams can result from combining too many scenarios and viewpoints into one diagram (Noran 2008, pg. 15). IDEF3 is a method that captures descriptions and is designed to tolerate inconsistent and partial descriptions. Most of the time those inconsistencies are the cause of organizations’ problems and they should be comprehensively dealt with in the IDEF3 representation and not glossed over and hidden. References Bernus, P., Mertins, K., & Schmidt, G. 1998, Handbook on Architectures of Information Systems (Second ed.), Springer-Verlag Berlin Heidelberg, Berlin, Heidelberg. Fowler, M., & Scott, K. 2000, UML distilled: a brief guide to the standard object modeling language (2nd ed.), Addison Wesley, Reading, Mass. Kim C. H. 2003, The complementary use of IDEF and UML modeling approaches Available at: http://www.sciencedirect.com/science/article/pii/S0166361502001458?np=y Lankhorst, M. 2005, Enterprise Architecture at Work Modeling, Communication, and Analysis, Springer-Verlag Berlin Heidelberg, Berlin, Heidelberg. Noran, O. S. 2008, A Meta-methodology for collaborative networked organizations: creating directly applicable methods for enterprise engineering projects, VDM Verlag Dr. Muller Saarbrucken, Germany. S?erifi, V. 2005, Functional and information modeling of production using IDEF methods, Wiley, London. Zhao Yong-peng 2010, Modeling and simulation for Equipment support system based on IDEF Method Available at:http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5620051 Read More