M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 2
Object-oriented analysis and design (OOAD) Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML). Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it. Object-oriented systems An object-oriented system is composed of objects. The behavior of the system results from the collaboration of those objects. Collaboration between objects involves them sending messages to each other. Sending a message differs from calling a function in that when a target object receives a message, it itself decides what function to carry out to service that message. The same message may be implemented by many different functions, the one selected depending on the state of the target object. The implementation of "message sending" varies depending on the architecture of the system being modeled, and the location of the objects being communicated with. Object-oriented analysis Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a conceptual model of the information that exists in the area being analyzed. Analysis models do not consider any implementation constraints that might exist, such as concurrency, distribution, persistence, or how the system is to be built. Implementation constraints are dealt with during object-oriented design (OOD). The sources for the analysis can be a written requirements statement, a formal vision document, interviews with stakeholders or other interested parties. A system may be divided into multiple domains, representing different business, technological, or other areas of interest, each of which are analyzed separately. The result of object-oriented analysis is a description of what the system is functionally required to do, in the form of a conceptual model. That will typically be presented as a set of use cases, one or more UML class diagrams, and a number of interaction diagrams. It may also include some kind of user interface mock-up. Object-oriented design Object-oriented design (OOD) transforms the conceptual model produced in object-oriented analysis to take account of the constraints imposed by the chosen architecture and any non-functionaltechnological or environmentalconstraints, such as transaction throughput, response time, run-time platform, development environment, or programming language. The concepts in the analysis model are mapped onto implementation classes and interfaces. The result is a model of the solution domain, a detailed description of how the system is to be built. What is an Object (computer science) In the programming paradigm of object-oriented programming, an object is the individual run-time unit that is used as the basic building block of programs. These objects act on each other, as opposed to a traditional view in which a program may be seen as a collection of functions, or simply as a list of instructions to the computer. Each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent little machine or actor with a distinct role or responsibility. M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 3
In the world of OOP (object-oriented programming), an object is an instantiation (instance) of a class. A class is only a blueprint offering a defined functionality. That functionality is actually implemented by creating an instance of that class, in form of an object. For example, a diagram of a computer monitor is a class (let's call it monitor_class). The actual computer monitor any particular computer user is looking into is an instance of that class, an object. Multiple objects of the monitor_class can be created, each using the functionality defined by the class. Hence, in the realm of software development, to use the functionality of a particular class, an object of that class must first be created. In the same way that to a person who wanted to drive a car, a specification of a car would not be of any use; what is needed is a real car constructed from that specification. Objects in object-oriented programming In object-oriented programming (OOP), an instance of a program (i.e. a program running in a computer) is treated as a dynamic set of interacting objects. Objects in OOP extend the more general notion of objects described above to include a very specific kind of typing, which among other things allows for: 1. data members that represent the data associated with the object. 2. methods that access the data members in predefined ways. In the case of most objects, the data members can only be accessed through the methods, making it easy to guarantee that the data will always remain in a well-defined state (class invariants will be enforced). Some languages do not make distinctions between data members and methods. In almost all object-oriented programming languages, a dot(.) operator is used to call a particular method/function of an object. For example, consider an arithmetic class named Arith_Class. This class contains functions like add(), subtract(), multiply() and divide(), that process results for two numbers sent to them. This class could be used to find the product of 78 and 69 by first of all creating an object of the class and then invoking its multiply method, as follows: 1 int result = 0; // Initialization 2 arith_Obj1 = new Arith_Class(); // Creating a new instance of Arith_Class 3 result = arith_Obj1.multiply(78,69); // Product of 78 and 69 stored in result variable In a language where each object is created from a class, an object is called an instance of that class. If each object has a type, two objects with the same class would have the same datatype. Creating an instance of a class is sometimes referred to as instantiating the class. A real-world example of an object would be "my dog", which is an instance of a type (a class) called "dog", which is a subclass of a class "animal". In the case of a polymorphic object, some details of its type can be selectively ignored, for example a "dog" object could be used by a function looking for an "animal". So could a "cat", because it too belongs to the class of "animal". While being accessed as an "animal", some member attributes of a "dog" or "cat" would remain unavailable, such as the "tail" attribute, because not all animals have tails. A ghost is an object that is unreferenced in a program, and can therefore serve no purpose. In a garbage- collected language, the garbage collector would mark the memory occupied by the object as free, although it would still contain the object's data until it was overwritten. Three properties characterize objects: 1. Identity: the property of an object that distinguishes it from other objects 2. State: describes the data stored in the object 3. Behavior: describes the methods in the object's interface by which the object can be used Some terms for specialized kinds of objects include: Singleton object: An object that is the only instance of its class during the lifetime of the program. M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 4
Functor (function object): an object with a single method (in C++, this method would be the function operator, "operator()") that acts much like a function (like a C/C++ pointer to a function). Immutable object: an object set up with a fixed state at creation time and which does not vary afterward. First-class object: an object that can be used without restriction. Container: an object that can contain other objects. Factory object: an object whose purpose is to create other objects. Metaobject: an object from which other objects can be created (Compare with class, which is not necessarily an object) Prototype: a specialized metaobject from which other objects can be created by copying God object: an object that knows too much or does too much. The God object is an example of an anti- pattern. Antiobjects: a computational metaphor useful to conceptualize and solve hard problems often with massively parallel approaches by swapping computational foreground and background. Object oriented design
Figure 1:An object Object oriented design is part of OO methodology and it forces programmers to think in terms of objects, rather than procedures, when they plan their code. An object contains encapsulated data and procedures grouped together to represent an entity. The 'object interface', how the object can be interacted, is also defined. An object oriented program is described by the interaction of these objects. Object Oriented Design is the discipline of defining the objects and their interactions to solve a business problem that was identified and documented during object oriented analysis. The origins of object oriented programming is structured programming. Structured programming fell short in big and complex programs. Object oriented methodology tries to remedy those shortfalls. The first object oriented languages were Simula and SmallTalk. The use of object oriented languages became popular after Grady Booch wrote the first paper titled Object-Oriented Design, in 1982. Object oriented design is defined as a programming language that has five conceptual tools to aid the programmer. These programs are often more readable than non-object oriented programs, and debugging becomes easier with locality. Input (sources) for object oriented design Conceptual model (must have): Conceptual model is the result of object-oriented analysis, it captures concepts in the problem domain. The conceptual model is explicitly chosen to be independent of implementation details, such as concurrency or data storage. Use case (must have): Use case is description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more scenarios that convey how the M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 5
system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. System Sequence Diagram (should have): System Sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter- system events. User interface documentations (if applicable): Document that shows and describes the look and feel of the end product's user interface. This is not mandatory to have, but helps to visualize the end-product and such helps the designer. Relational data model (if applicable): A data model is an abstract model that describes how data is represented and used. If not object database is used, usually the relational data model should be created before the design can start. How the relational to object mapping is done is included to the OO design. Object oriented concepts supported by an OO language The five basic concepts of object oriented design are the implementation level features that are built into the programming language. These features are often referred to by these common names: Encapsulation: A tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is often the implementation of a class). Information hiding: The ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class. Inheritance: The ability for a class to extend or override functionality of another class. The so called child class has a whole section that is the parent class and then it has its own set of functions and data. Interface: A definition of functions or methods, and their signatures that are available for use to manipulate a given instance of an object. Polymorphism: The ability to define different functions or classes as having the same name but taking different data types. Designing concepts Defining objects, creating class diagram from conceptual diagram: Usually map entity to class. Identifying attributes. Use design patterns (if applicable): A design pattern is not a finished design, it is a description of a solution to a common problem. The main advantage of using a design pattern is that it can be reused in multiple applications. It can also be thought of as a template for how to solve a problem that can be used in many different situations and/or applications. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Define application framework (if applicable): Application framework is a term usually used to refer to a set of libraries or classes that are used to implement the standard structure of an application for a specific operating system. By bundling a large amount of reusable code into a framework, much time is saved for the developer, since he/she is saved the task of rewriting large amounts of standard code for each new application that is developed. Identify persisted objects/data (if applicable): Identify objects that have to be persisted. If relational database is used design the object relation mapping. Identify, define remote objects (if applicable) M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 6
Output (deliverables) of object oriented design Class diagram: Class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. Sequence diagram: Expend the System Sequence Diagram to add specific objects that handle the system events. Usually we create sequence diagram for important and complex system events, not for simple or trivial ones. A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. Programming concepts Aspect oriented programming: One view of aspect-oriented programming (AOP) is that every major feature of the program, core concern (business logic), or cross-cutting concern (additional features), is an aspect, and by weaving them together (also called composition), you finally produce a whole out of the separate aspects. Dependency injection: The basic idea is that if an object depends upon having an instance of some other object then the needed object is "injected" into the dependent object. For example, being passed a database connection as an argument to the constructor instead of creating one internally Acyclic Dependencies Principle: The dependency graph of packages or components should have no cycles. This is also referred to as having a Directed Acyclic Graph. For example, package C depends on package B, which depends on package A. If package A also depended on package C, then you would have a cycle. Composite Reuse Principle: Favor polymorphic composition of objects over inheritance. Current OO languages Some modern languages that endorse object oriented design practices: ActionScript CLOS (an expansion of the Lisp Programming Language) C++ C# Eiffel Java PHP Objective-C Python Ruby Simula SmallTalk VB.Net Delphi Object-Oriented Modeling Object-Oriented Modeling, or OOM, is a modeling paradigm mainly used in computer programming. Prior to the rise of OOM, the dominant paradigm was functional programming, which emphasised the use of discreet reusable code blocks that could stand on their own, take variables, perform a function on them, and return values. The Object-Oriented paradigm assists the programmer to address the complexity of a problem domain by considering the problem not as a set of functions that can be performed but primarily as a set of related, interacting Objects. The modeling task then is specifying, for a specific context, those Objects (or the Class the M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 7
Objects belongs to), their respective set of Properties and Methods, shared by all Objects members of the Class. For more discussion, see Object-oriented analysis and design and Object-oriented programming. The description of these Objects is a Schema. As an example, in a model of a Payroll System, a Company is an Object. An Employee is another Object. Employment is a Relationship or Association. An Employee Class (or Object for simplicity) has Attributes like Name, Birthdate, etc. The Association itself may be considered as an Object, having Attributes, or Qualifiers like Position, etc. An Employee Method may be Promote, Raise, etc. The Model description or Schema may grow in complexity to require a Notation. Many notations has been proposed, based on different paradigms, diverged, and converged in a more popular one known as UML. An informal description or a Schema notation is translated by the programmer or a Computer-Aided Software Engineering tool in the case of Schema notation (created using a Module specific to the CASE tool application) into a specific programming language that supports Object-Oriented Programming (or a Class Type), a Declarative Language or into a Database schema. Object modeling language An Object Modeling Language is a standardized set of symbols and ways of arranging them to model (part of) an object oriented software design or system design. Some organizations use them extensively in combination with a software development methodology to progress from initial specification to an implementation plan and to communicate that plan to an entire team of developers and stakeholders. Because a modeling language is visual and at a higher-level of abstraction than code, using models encourages the generation of a shared vision that may prevent problems of differing interpretation later in development. Often software modeling tools are used to construct these models, which may then be capable of automatic translation to code. First Generation In the first generation, isolated methodologists and small groups developed techniques that solved problems they saw first-hand in Object Oriented (OO) development projects. The first generation includes techniques such as: Booch method Class-Responsibility-Collaboration card (CRC) Object-modeling technique (OMT) Object-oriented software engineering (OOSE) Shlaer-Mellor Yourdon-Coad (see Edward Yourdon) The first generation languages were co-developed and very closely tied with specific object-oriented methodologies usually with the same name. It was often difficult to determine whether the notation or methodology was being referred to. Second Generation The second generation recognized that many best practices were scattered among the fragmented OO methodology landscape. Several attempts were made to gather these practices into coherent frameworks such as FUSION. However, the OO community was beginning to recognize the benefits that industry standardization would bring: not just a good way of doing things, but the good way, which would lead to common parlance and practice among developers. M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 8 Third Generation The third generation consists of credible attempts at this single industry-standard language, with Unified Modeling Language (UML) being the primary example. By this time, the futility of standardizing the method was recognized, and the languages developed into notations that are suitable for a wide range of development methods. Booch method
Class diagram The Booch method is a technique used in software engineering. It is an object modeling language and methodology that was widely used in object-oriented analysis and design. It was developed by Grady Booch while at Rational Software (now part of IBM). The notation aspect of the Booch method has now been superseded by the Unified Modeling Language (UML), which features graphical elements from the Booch method along with elements from the object-modeling technique (OMT) and object-oriented software engineering (OOSE). Methodological aspects of the Booch method have been incorporated into several methodologies and processes, the primary such methodology being the Rational Unified Process (RUP). Class-Responsibility-Collaboration card Class-Responsibility-Collaboration cards (CRC cards) are a brainstorming tool used in the design of object- oriented software. They were proposed by Ward Cunningham. They are typically used when first determining which classes are needed and how they will interact. CRC cards are usually created from index cards on which are written: 1. The class name 2. Its Super and Sub classes (if applicable) 3. The responsibilities of the class. 4. The names of other classes that the class will collaborate with to fulfill its responsibilities. 5. Author Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people. A common method to determine what cards should be created is to read a specification for the program being designed and consider if each noun should be a class and if each verb should be a responsibility of the noun or class that it belongs to. Naturally, the existence of a noun or verb does not require a class or responsibility in the program, but it is considered a good starting point. M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 9 Object-modeling technique
OMT object diagram
OMT state diagram The object-modeling technique (OMT) is an object modeling language for software modeling and designing. It was developed circa 1991 by Rumbaugh, Blaha, Premerlani, Eddy and Lorensen as a method to develop object- oriented systems, and to support object-oriented programming. OMT is a predecessor to the Unified Modeling Language (UML). Many OMT modeling elements are common to UML. Object-oriented software engineering Object-oriented software engineering (OOSE) is an object modeling language and methodology OOSE was developed by Ivar Jacobson in 1992 while at Objectory AB. It is the first object-oriented design methodology to employ use cases to drive software design. It also uses other design products similar to those used by OMT. The tool Objectory was created by the team at Objectory AB to implement the OOSE methodology. After success in the marketplace, other tool vendors also supported OOSE. After Rational bought Objectory AB, the OOSE notation, methodology, and tools became superseded. As one of the primary sources of the Unified Modeling Language (UML), concepts and notation from OOSE have been incorporated into UML. The methodology part of OOSE has since evolved into the Rational Unified Process (RUP). The OOSE tools have been replaced by tools supporting UML and RUP. OOSE has been largely replaced by the UML notation and by the RUP methodology. Shlaer-Mellor The Shlaer-Mellor method, developed by Sally Shlaer and Stephen J. Mellor, is one of a number of object- oriented analysis (OOA) / object-oriented design (OOD) methods which arrived in the late 1980s in response to perceived weaknesses in the existing structured analysis and structured design (SASD) techniques in use by (primarily) software engineers. M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 10
Of these perceived problems, Shlaer and Mellor chose to address: The complexity of designs generated through the use of SASD. The problem of maintaining analysis and design documentation over time. Principles of Modelling Structural modeling perspective This approach concentrates on describing the static structure. The main concept in this modeling perspective is the entity, this could be an object, phenomena, concept, thing etc. The data modeling languages have traditionally handled this perspective, examples of such being: The ER-language (Entity-Relationship) Generic Semantic Modeling language. (GSM) Other approaches including: The NIAM language (Binary relationship language) Conceptual graphs (Sowa) Looking at the ER-language we have the basic components: Entities: Distinctively identifiable phenomenon. Relationships: An association among the entities. Attributes: Used to give value to a property of an entity/relationship. Looking at the generic semantic modeling language we have the basic components: Constructed types built by abstraction: Aggregation, generalization, and association. Attributes. Primitive types: Data types in GSM are classified into printable and abstract types. Printable: Used to specify visible values. Abstract: Representing entities. Functional modeling perspective This approach concentrates on describing the dynamic process. The main concept in this modeling perspective is the process, this could be a function, transformation, activity, action, task etc. A well-known example of a modeling language employing this perspective is data flow diagrams. The perspective uses four symbols to describe a process, these being: Process: Illustrates transformation from input to output. Store: Data-collection or some sort of material. Flow: Movement of data or material in the process. External Entity: External to the modeled system, but interacts with it. Now, with these symbols, a process can be represented as a network of these symbols. This decomposed process is a DFD, data flow diagram. M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 11 Behavioral perspective Behavioral perspective gives a description of system dynamics. The main concepts in behavioral perspective are states and transitions between states. State transitions are triggered by events. State Transition Diagrams (STD/STM), State charts and Petri-nets are some examples of well-known behaviorally oriented modeling languages. Different types of State Transition Diagrams are used particularly within real-time systems and telecommunications systems. Rule perspective Rule perspective gives a description of goals/means connections. The main concepts in rule perspective are rule, goal and constraint. A rule is something that influences the actions of a set of actors. The standard form of rule is IF condition THEN action/expression. Rule hierarchies (goal-oriented modeling), Tempora and Expert systems are some examples of rule oriented modeling. Object perspective The object-oriented perspective describes the world as autonomous, communicating objects. An object is an entity which has a unique and unchangeable identifier and a local state consisting of a collection of attributes with assignable values. The state can only be manipulated with a set of methods defined on the object. The value of the state can only be accessed by sending a message to the object to call on one of its methods. An event is when an operation is being triggered by receiving a message, and the trace of the events during the existence of the object is called the objects life cycle or the process of an object. Several objects that share the same definitions of attributes and operations can be parts of an object class. The perspective is originally based on design and programming of oriented systems. Unified Modelling Language (UML) is a well known language for modelling with an object perspective. Communication perspective This perspective is based on language/action theory from philosophical linguistics. The basic assumption in this perspective is that person/objects cooperate on a process/action thorough communication within them. An illocutionary act consists of five elements: Speaker, hearer, time, location and circumstances. It is a reason and goal for the communication, where the participations in a communication act is oriented towards mutual agreement. In a communication act, the speaker generally can raise three claims: truth (referring an object), justice (referring a social world of the participations) and claim to sincerity (referring the subjective world of the speaker). Actor and role perspective Actor and role perspective is a description of organisational and system structure. An actor can be defined as a phenomenon that influences the history of another actor, whereas a role can be defined as the behaviour which is expected by an actor, amongst other actors, when filling the role. Modelling within these perspectives is based both on work with object-oriented programming languages and work with intelligent agents in artificial intelligence. When modelling with an actor perspective, the focus is on who and why, and to improve the understanding of needs and the structure of requirements. I* is an example of an actor oriented language. Model-Driven Engineering Model-Driven Engineering (or MDE) refers to the systematic use of models as primary engineering artifacts throughout the engineering lifecycle. MDE can be applied to software, system, and data engineering. Models are considered as first class entities. The best known MDE initiative is the Object Management Group (OMG) called Model-Driven Architecture (MDA), which is a registered trademark of OMG. Another related acronym is Model- Driven Development (MDD) which is also a OMG trademark. As it pertains to software development, Model-Driven Development refers to a range of development approaches that are based on the use of software modeling as a primary form of expression. Sometimes models are constructed to a certain level of detail, and then code is written by hand in a separate step. Sometimes complete models are built including executable actions. Code can be generated from the models, ranging from system M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 12
skeletons to complete, deployable products. With the introduction of the Unified Modeling Language (UML), MDD has become very popular today with a wide body of practitioners and supporting tools. More advanced types of MDD have expanded to permit industry standards which allow for consistent application and results. The continued evolution of MDD has added an increased focus on architecture and automation. MDD technologies with a greater focus on architecture and corresponding automation yield higher levels of abstraction in software development. This abstraction promotes simpler models with a greater focus on problem space. Combined with executable semantics this elevates the total level of automation possible. The Object Management Group (OMG) has developed a set of standards called Model Driven Architecture (MDA), building a foundation for this advanced architecture-focused approach. Model Integrated Computing is yet another branch of MDE. According to Douglas Schmidt, model-driven engineering technologies offer a promising approach to address the inability of third-generation languages to alleviate the complexity of platforms and express domain concepts effectively. Modeling language A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure. A modeling language can be graphical or textual. Graphical modeling languages use a diagram techniques with named symbols that represent concepts and lines that connect the symbols and that represent relationships and various other graphical annotation to represent constraints. Textual modeling languages typically use standardised keywords accompanied by parameters to make computer-interpretable expressions. An example of a graphical modeling language and a corresponding textual modeling language is EXPRESS-G and EXPRESS (ISO 10303-11). Not all modeling languages are executable, and for those that are, the use of them doesn't necessarily mean that programmers are no longer required. On the contrary, executable modeling languages are intended to amplify the productivity of skilled programmers, so that they can address more challenging problems, such as parallel computing and distributed systems. A large number of modeling languages appear in the literature. Examples Example of modelling languages are: EXPRESS and EXPRESS-G (ISO 10303-11) is an international standard general-purpose data modeling language. It is used among others to specify various ISO standard data models, such as the application protocols of ISO 10303 (STEP), ISO 13584, ISO 15926 and others. Unified Modeling Language (UML) is a general-purpose modeling language that is an industry standard for specifying software-intensive systems. UML 2.0, the current version, supports thirteen different diagram techniques, and has widespread tool support. Petri nets use variations on exactly one diagramming technique and topology, namely the bipartite graph. The simplicity of its basic user interface easily enabled extensive tool support over the years, particularly in the areas of model checking, graphically-oriented simulation, and software verification. IDEF is a family of modeling languages, the most notable of which include IDEF0, for functional modeling, and IDEF1 for information modeling. M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT 13
SysML is a Domain-Specific Modeling language for systems engineering that is defined as a UML profile (customization). Energy Systems Language (ESL), a language that aims to model ecological energetics & global economics. Business Process Modeling Notation (BPNM, and the XML form BPML) is an example of a Process Modeling language. Fundamental Modeling Concepts (FMC) modeling language for software-intensive systems. Gellish English, a structured subset of natural English, which includes a Gellish English dictionary and in which facts are expressed in a standardised Gellish Database Table. Gellish English is not a meta language, but integrates and upper ontology with domain ontologies in one language. Applications Various kinds of modeling languages are applied in different disciplines, including computer science, information management, business process modeling, software engineering, and systems engineering. Modeling languages can be used to specify system requirements, structures and behaviors. Modeling languages are intended to be used to precisely specify systems so that stakeholders (e.g., customers, operators, analysts, designers) can better understand the system being modeled. The more mature modeling languages are precise, consistent and executable. Informal diagramming techniques applied with drawing tools are expected to produce useful pictorial representations of system requirements, structures and behaviors, but not much else. Executable modeling languages applied with proper tool support, however, are expected to automate system verification, validation, simulation and code generation from the same representations.
ChatGPT Millionaire 2024 - Bot-Driven Side Hustles, Prompt Engineering Shortcut Secrets, and Automated Income Streams that Print Money While You Sleep. The Ultimate Beginner’s Guide for AI Business
ChatGPT Side Hustles 2024 - Unlock the Digital Goldmine and Get AI Working for You Fast with More Than 85 Side Hustle Ideas to Boost Passive Income, Create New Cash Flow, and Get Ahead of the Curve