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. 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. 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 ordered 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. IDEF0 modeling generally begins by defining a context diagram. This is representative of the system’s overall purpose and its interfaces with external environments. Usually, IDEF0 models consist of a hierarchy of connected diagrams that are decomposed hierarchically hence encoding semantic data at lower levels of modeling. The hierarchical breakdown results in 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 information models that symbolize both the semantics and structure of data that is found in a target system or environment. It is a notation that is an extension to the IDEF1 notation and offers a semantic data modeling method that can support the design of conceptual schemas (Šerifi 2005, pg. 39). IDEF1x has similar modeling constructs and concepts to those normally found in E-R (entity-relationship) models. It supports and enables formal representation of attributes, entities, and relationships between entities. 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 three 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 (Šerifi 2005, pg. 34). PFNs represent the conditions under which, and the sequence in which, a system performs activities. OSTN defines the transition states that an object 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 Cases and Use Case Diagrams These define the generic processes that a system should be able to handle. Their building blocks are actors, use cases, and the type of system designed. The use case defines a task that has to be performed with support from the system, or the functionality offered by the system. An actor (also known as a stick person) is usually not part of the system; an actor is an external entity that should engage/interact with the system. An actor is neither a class nor a type, but an instance (Fowler & Scott 2000, pg. 41). Every actor symbolizes a role and not a single user of the system. Actors interact with the system by sending and receiving messages, and when they send a message to the system a use case is triggered. ii) Class Programs and Static Modeling “Class” is a descriptor that is used in UML modeling to denote a group of objects with similar relationships, behavior, and data structure (Bernus, Mertins, & Schmidt 1998, pg. 52). Class diagrams can be used to present a static view of a system with respect to the relationships among classes and their object classes. In spite of this, class diagrams do not encode information 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. 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 (Š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. UML also offers modeling constructs to build 4 kinds of dynamic diagrams which are: activity diagrams, sequence diagrams, state diagrams, and collaboration diagrams. 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. 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 (Š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. 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. 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. Šerifi, V. 2005, Functional and information modeling of production using IDEF methods, Wiley, London. Read More