Today, faced with an embarrassingly rich array of middleware platforms, the developer has three different middleware problems: First, selecting one; second, getting it to work with the other platforms already deployed not only in his own shop, but also those of his customers and suppliers; and third, interfacing to (or, worse yet, migrating to) a new "Next Best Thing" when a new platform comes along and catches the fancy of the analysts and, necessarily, CIOs everywhere.
MODELS VS. METHODOLOGIES
The process of gathering and analyzing an application's requirements, and incorporating them into a program design, is a complex one and the industry currently supports many methodologies that define formal procedures specifying how to go about it. In fact, the one that enables the widespread industry support that the language enjoys - is that it is methodology-independent. Regardless of the methodology that you use to perform your analysis and design, you can use the model to express the results.
SURVEY SAYS...
Surveys show that large software projects have a huge probability of failure - in fact, it's more likely that a large software application will fail to meet all of its requirements on time and on budget than that it will succeed. If you're running one of these projects, you need to do all you can to increase the odds for success, and modeling is the only way to visualize your design and check it against requirements before your crew starts to code.
SURVEY SAYS...
Surveys show that large software projects have a huge probability of failure - in fact, it's more likely that a large software application will fail to meet all of its requirements on time and on budget than that it will succeed. If you're running one of these projects, you need to do all you can to increase the odds for success, and modeling is the only way to visualize your design and check it against requirements before your crew starts to code.
MODEL ANY TYPE OF APPLICATION
You can model just about any type of application, running on any type and combination of hardware, operating system, programming language, and network, in UML. Its flexibility lets you model distributed applications that use just about any middleware on the market. Built upon fundamental OO concepts including class and operation, it's a natural fit for object-oriented languages and environments such as C++, Java, and the recent C#, but you can use it to model non-OO applications as well in, for example, Fortran, VB, or COBOL.
ENTER UNIFIED MODELING LANGUAGE (UML)
With many rapid application development environments available, developing a software application is fairly easy so why use UML? Most people are familiar with a drawing package can design and create forms and most people with basic programming skills can double click on a control and enter some code. But does this approach lend itself to professional quality applications?
Deborah Kurata (1998) stated that if an application is to be of professional quality it must:
- Meet the needs of the users
- Be robust
- Be maintainable
- Be documented
With the use of UML, an appropriate UML development tool, and an application process or methodology, the design and refining of the application is shifted from the development phase to an analysis and design phase. This reduces risk and provides a vehicle for testing the architecture of the system before coding begins. The analysis and design overhead will eventually pay dividends as the system has been user driven, documented and when it’s time to start developing, many UML tools will generate skeleton code that will be efficient, object oriented and promote re-use.
Sinan Si Alhir (1998) describes UML as enabling:
“…the capturing, communicating and leveraging of strategic, tactical and operational knowledge to facilitate increasing value by increasing quality, reducing costs and reducing time-to-market while managing risks and being proactive in regard to ever-increasing change and complexity.”
Furthermore, the use of UML will help:
- The communication of the desired structure and behavior of a system between analysts, architects, developers, stakeholders and users.
- The visualization and control of system architecture.
- Promote a deeper understanding of the system, exposing opportunities for simplification and re-use.
- Manage risk.
UML achieves this using UML models.
UNIFIED MODELING LANGUAGE (UML)
The UML architecture is based on the meta object facility, which defines the foundation for creating modeling language. They are precise enough to generate the entire application. A fully executable UML can be deployed to multiple platforms using different technologies and can be used with all processes throughout the software development cycle.
UML is designed to enable users to develop an expressive, ready to use visual modeling language. In addition, it supports high level development concepts such as frameworks, patterns and collaborations.
PROGRAMMING LANGUAGE STATMENTS
- Actors: specify a role played by a user or any other system interacting with the subject.
- Activities: These are tasks, which must take place in order to fulfill an operation contract. They are represented in activity diagrams.
- Business Process: includes a collection of tasks producing a specific service for customers and is visualized with a flowchart as a sequence of activities.
SOFTWARE COMPONENTS
UML is linked with object-oriented design and analysis. UML makes the use of elements and forms associations between them to form diagrams. Diagrams in UML can be broadly classified as Structural and Behavioral:
The image below shows the hierarchy of diagrams according to UML 2.2
The image below shows the hierarchy of diagrams according to UML 2.2
Structural Diagrams – Capture static aspects or structure of a system. Structural Diagrams include: includes six diagram types representing structural information:
Class Diagram – The most widely use UML diagram is the class diagram. It is the building block of all object-oriented software systems. We use class diagrams to depict the static structure of a system by showing system’s classes, their methods and attributes. Class diagrams also help us identify relationship between different classes or objects.
Composite Structure Diagram – We use composite structure diagrams to represent the internal structure of a class and its interaction points with other parts of the system. A composite structure diagram represents relationship between parts and their configuration which determine how the classifier (class, a component, or a deployment node) behaves. They represent internal structure of a structured classifier making the use of parts, ports, and connectors. We can also model collaborations using composite structure diagrams. They are similar to class diagrams except they represent individual parts in detail as compared to the entire class.
Object Diagram – An Object Diagram can be referred to as a screenshot of the instances in a system and the relationship that exists between them. Since object diagrams depict behavior when objects have been instantiated, we are able to study the behavior of the system at a particular instant. An object diagram is similar to a class diagram except it shows the instances of classes in the system. We depict actual classifiers and their relationships making the use of class diagrams. On the other hand, an Object Diagram represents specific instances of classes and relationships between them at a point of time.
Component Diagram – Component diagrams are used to represent the how the physical components in a system have been organized. We use them for modelling implementation details. Component Diagrams depict the structural relationship between software system elements and help us in understanding if functional requirements have been covered by planned development. Component Diagrams become essential to use when we design and build complex systems. Interfaces are used by components of the system to communicate with each other.
Deployment Diagram – Deployment Diagrams are used to represent system hardware and its software. It tells us what hardware components exist and what software components run on them. We illustrate system architecture as distribution of software artifacts over distributed targets. An artifact is the information that is generated by system software. They are primarily used when a software is being used, distributed or deployed over multiple machines with different configurations.
Package Diagram – We use Package Diagrams to depict how packages and their elements have been organized. A package diagram simply shows us the dependencies between different packages and internal composition of packages. Packages help us to organize UML diagrams into meaningful groups and make the diagram easy to understand. They are primarily used to organize class and use case diagrams.
Behavior Diagrams – Capture dynamic aspects or behavior of the system. Behavior diagrams include: Use Case Diagrams, State Diagrams, Activity Diagrams and Interaction Diagrams.
State Machine Diagrams – A state diagram is used to represent the condition of the system or part of the system at finite instances of time. It’s a behavioral diagram and it represents the behavior using finite state transitions. State diagrams are also referred to as State machines and State-chart Diagrams. These terms are often used interchangeably. So simply, a state diagram is used to model the dynamic behavior of a class in response to time and changing external stimuli.
Activity Diagrams – We use Activity Diagrams to illustrate the flow of control in a system. We can also use an activity diagram to refer to the steps involved in the execution of a use case. We model sequential and concurrent activities using activity diagrams. So, we basically depict workflows visually using an activity diagram. An activity diagram focuses on condition of flow and the sequence in which it happens. We describe or depict what causes a particular event using an activity diagram.
Use Case Diagrams – Use Case Diagrams are used to depict the functionality of a system or a part of a system. They are widely used to illustrate the functional requirements of the system and its interaction with external agents(actors). A use case is basically a diagram representing different scenarios where the system can be used. A use case diagram gives us a high-level view of what the system or a part of the system does without going into implementation details.
Sequence Diagram – A sequence diagram simply depicts interaction between objects in a sequential order i.e. the order in which these interactions take place. We can also use the terms event diagrams or event scenarios to refer to a sequence diagram. Sequence diagrams describe how and in what order the objects in a system function. These diagrams are widely used by businessmen and software developers to document and understand requirements for new and existing systems.
Communication Diagram – A Communication Diagram (known as Collaboration Diagram in UML 1.x) is used to show sequenced messages exchanged between objects. A communication diagram focuses primarily on objects and their relationships. We can represent similar information using Sequence diagrams, however, communication diagrams represent objects and links in a free form.
Timing Diagram – Timing Diagram are a special form of Sequence diagrams which are used to depict the behavior of objects over a time frame. We use them to show time and duration constraints which govern changes in states and behavior of objects.
Interaction Overview Diagram – An Interaction Overview Diagram models a sequence of actions and helps us simplify complex interactions into simpler occurrences. It is a mixture of activity and sequence diagrams.
The image below shows the hierarchy of diagrams according to UML 2.2
UML’S OBJECT ORIENTED DESIGN FACETS
- Class – A class defines the blue print i.e. structure and functions of an object.
- Objects – Objects help us to decompose large systems and help us to modularize our system. Modularity helps to divide our system into understandable components so that we can build our system piece by piece. An object is the fundamental unit (building block) of a system which is used to depict an entity.
- Inheritance – Inheritance is a mechanism by which child classes inherit the properties of their parent classes.
- Abstraction – Mechanism by which implementation details are hidden from user.
- Encapsulation – Binding data together and protecting it from the outer world is referred to as encapsulation.
- Polymorphism – Mechanism by which functions or entities are able to exist in different forms.
UML THE SEQUEL
Originally UML specified 9 diagrams. UML 2.x has increased the number of diagrams from 9 to 13. The four diagrams that were added are: timing diagram, communication diagram, interaction overview diagram and composite structure diagram. UML 2.x renamed statechart diagrams to state machine diagrams.
- Software development methodologies like agile have been incorporated the and scope of original UML specification has been broadened.
- Added diagrams: Originally UML specified 9 diagrams. UML 2.x has increased the number of diagrams from 9 to 13. The four diagrams that were added are: timing diagram, communication diagram, interaction overview diagram and composite structure diagram. UML 2.x renamed statechart diagrams to state machine diagrams.
- More deliniation: UML 2.x added the ability to decompose software system into components and sub-components
- Nested Classifiers: This is an extremely powerful concept. In UML, almost every model building block you work with (classes, objects, components, behaviors such as activities and state machines, and more) is a classifier. In UML 2.0, you can nest a set of classes inside the component that manages them, or embed a behavior (such as a state machine) inside the class or component that implements it. This capability also lets you build up complex behaviors from simpler ones, the capability that defines the Interaction Overview Diagram. You can layer different levels of abstraction in multiple ways: For example, you can build a model of your Enterprise, and zoom in to embedded site views, and then to departmental views within the site, and then to applications within a department. Alternatively, you can nest computational models within a business process model. OMG's Business Enterprise Integration Domain Task Force (BEI DTF) is currently working on several interesting new standards in the business process and business rules.
- Improved Behavioral Modeling: In UML 1.X, the different behavioral models were independent, but in UML 2.0, they all derive from a fundamental definition of a behavior (except for the Use Case, which is subtly different but still participates in the new organization).
- Improved relationship between Structural and Behavioral Models: As we pointed out under Nested Classifiers, UML 2.0 lets you designate that a behavior represented by (for example) a State Machine or Sequence Diagram is the behavior of a class or a component.
HOW DO WE GET THERE FROM HERE?
A wide variety of UML modeling tools are available to simplify the modeling process, including IBM Rational Rose, Rational Rhapsody, MagicDraw UML, StarUML, ArgoUML,
Umbrello, BOUML, PowerDesigner and Dia.
CONCLUSION
UML is that outside wave in the distance that you know if your going to catch you have to swim out to it. It's the one thing that enables the widespread industry support that the language enjoys - is that it is methodology-independent. Regardless of the methodology that you use to perform your analysis and design, you can use the model to express the results.
UML is not a programming language; it is rather a visual language. We use UML diagrams to portray the behavior and structure of a system. UML helps software engineers, businessmen and system architects with modelling, design and analysis.
References
“Once more unto the breach, dear friends, once more;”
About Rick Ricker
UML is not a programming language; it is rather a visual language. We use UML diagrams to portray the behavior and structure of a system. UML helps software engineers, businessmen and system architects with modelling, design and analysis.
You can model just about any type of application, running on any type and combination of hardware, operating system, programming language, and network, in UML. Its flexibility lets you model distributed applications that use just about any middleware on the market. Built upon fundamental OO concepts including class and operation, it's a natural fit for object-oriented languages and environments such as C++, Java, and the recent C#, but you can use it to model non-OO applications as well in, for example, Fortran, VB, or COBOL.
References
- https://www.opsgenie.com/producthttps://www.guru99.com/best-uml-tools.html
- http://dthomas-software.co.uk/resources/frequently-asked-questions/why-use-uml-2/
- https://www.uml.org/what-is-uml.htm
- https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/
- https://www.techopedia.com/definition/3243/unified-modeling-language-uml
_______________________________________________________
“Once more unto the breach, dear friends, once more;”
___________________________________________
We would like to thank our sponsors, for without them - our fine content wouldn't be deliverable!
About Rick Ricker
An IT professional with over 23 years experience in Information Security, wireless broadband, network and Infrastructure design, development, and support.
For more information, contact Rick at (800) 399-6085 x502
For more information, contact Rick at (800) 399-6085 x502
No comments:
Post a Comment
Thanks for your input, your ideas, critiques, suggestions are always welcome...
- Wasabi Roll Staff