Unit-5:Unified Modeling Languages (UML):
What is UML?
UML stands for Unified Modeling Language.
It is a standard notation for the modeling of real world objects as a first step in developing an object-oriented methodology.
It is a general purpose, developmental, modeling language in the field of software engineering, which is intended to provide a standard way to visualize the design of a system.
It is a standard visual modeling language which is used for modeling business and similar processes. Analysis, design and implementation of software based systems.
It is a standard modeling language, not a software development process.
It is intentionally process independent and could be applied in the context of different processes.
History of UML
It was developed by Grady Booch, Ivar Jacobson, James Rumbaugh at Rational Software in 1994-95.
It was motivated by the desire to standardize the disparate notational systems and approaches to software design.
It was adopted as a standard by the Object Management Group (OMG) in 1997 and has been managed by this organization.
It was also published by the International Organization for Standardization (ISO) as an approved ISO standard in 2005.
It is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems.
Advantages of UML
It provides a standard for software development.
It reduces the cost to develop diagrams of UML using supporting tools.
It reduces the development time.
The past faced issues by the developers no longer exists.
It has a large visual element to construct and are easy to follow.
Working with a new developer will be easier.
Communication with programmers and outside contractors will be more efficient.
Types/Applications of UML Diagrams
1. Use Case Diagram
It defines the detail description of a system's behavior from a user's point of view.
2. Class Diagram
It displays relationships, such as containment and inheritance.
It contains the model class structure and contents using design elements such as classes, packages and objects.
3. Sequence Diagram
It shows time-based dynamics of the interaction between objects.
4. Collaboration Diagram
It displays the interaction organized around the objects and their links to the one another.
5. State Diagram
It displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli.
6. Activity Diagram
It displays a special state diagram where most of the states are action states and most of the transitions are triggered by the completion of the actions in the source states.
7. Component Diagram
It displays the high level packaged structure of the code itself.
8. Deployment Diagram
It displays the configuration of run-time processing elements and the software components, processes and objects that live on them.
Disadvantages of UML
It does not define a standard file format, that means each UML tool vendor stores the representation of its UML model in proprietary format.
This model is limited to what the vendor provides out of the box, which is usually some form of a code generator.
It is large and complex.
It is difficult to synchronize the code with models.
It is difficult to keep multiple models or diagrams consistent with each other.
UML Diagrams
Types/Applications of UML Diagrams
1. Use Case Diagram
It defines the detail description of a system's behavior from a user's point of view.
2. Class Diagram
It displays relationships, such as containment and inheritance.
It contains the model class structure and contents using design elements such as classes, packages and objects.
3. Sequence Diagram
It shows time-based dynamics of the interaction between objects.
4. Collaboration Diagram
It displays the interaction organized around the objects and their links to the one another.
5. State Diagram
It displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli.
6. Activity Diagram
It displays a special state diagram where most of the states are action states and most of the transitions are triggered by the completion of the actions in the source states.
7. Component Diagram
It displays the high level packaged structure of the code itself.
8. Deployment Diagram
It displays the configuration of run-time processing elements and the software components, processes and objects that live on them.
Disadvantages of UML
It does not define a standard file format, that means each UML tool vendor stores the representation of its UML model in proprietary format.
This model is limited to what the vendor provides out of the box, which is usually some form of a code generator.
It is large and complex.
It is difficult to synchronize the code with models.
It is difficult to keep multiple models or diagrams consistent with each other.
Write a short note on UML metamodel.
What is UML metamodel?
It is a model of a model.
It is the process of generating such metamodels.
It is the analysis, construction and development of the frames, rules, constraints and models.
It is contained in packages, which logically separate into different design layers.
It is extended by using object-oriented principles to define the UML superstructure.
Static and Dynamic Models,
There are two kinds of object models: dynamic and static. Dynamic models, such as UML interaction diagrams (sequence diagrams or communication diagrams), help design the logic, the behavior of the code or the method bodies. They tend to be the more interesting, difficult, important diagrams to create. Static models, such as UML class diagrams, help design the definition of packages, class names, attributes, and method signatures (but not method bodies).
Static and dynamic UML diagrams for object modeling
There's a relationship between static and dynamic modeling and the agile modeling practice of create models in parallel: Spend a short period of time on interaction diagrams (dynamics), then switch to a wall of related class diagrams (statics).
Dynamic Object Modeling
People new to UML tend to think that the important diagram is the static - view class diagram, but in fact, most of the challenging, interesting, useful design work happens while drawing the UML dynamic - view interaction diagrams. It's during dynamic object modeling (such as drawing sequence diagrams) that "the rubber hits the road" in terms of really thinking through the exact details of what objects need to exist and how they collaborate via messages and methods. Therefore, this book starts by introducing dynamic object modeling with interaction diagrams.
Note that it's especially during dynamic modeling that we apply responsibility - driven designand the GRASPprinciples. The subsequent chapters focus on these key topics of the book - and key skills in 00 design.
Static Object Modeling
The most common static object modeling is with UML class diagrams. After first covering dynamic modeling with interaction diagrams, I introduce the details.
Note, though, that if the developers are applying the agile modeling practice of Create several models in parallel, they will be drawing both interaction and class diagrams concurrently.
The Importance of Object Design Skill over UML Notation Skill
The following chapters explore detailed object design while applying UML diagrams. It's been said before, but is important to stress: What's important is knowing how to think and design in objects, and apply object design best - practice patterns, which is a very different and much more valuable skill than knowing UML notation.
While drawing a UML object diagram, we need to answer key questions: What are the responsibilities of the object? Who does it collaborate with? What design patterns should be applied? Far more important than knowing the difference between UML 1.4 and 2.0 notation! Therefore, the emphasis of the following chapters is on these principles and patterns in object design.
UML Diagrams
UML Class Diagrams
The class diagram depicts a static view of an application. It represents the types of objects residing in the system and the relationships between them. A class consists of its objects, and also it may inherit from other classes. A class diagram is used to visualize, describe, document various different aspects of the system, and also construct executable software code.
It shows the attributes, classes, functions, and relationships to give an overview of the software system. It constitutes class names, attributes, and functions in a separate compartment that helps in software development. Since it is a collection of classes, interfaces, associations, collaborations, and constraints, it is termed as a structural diagram.
Purpose of Class Diagrams
The main purpose of class diagrams is to build a static view of an application. It is the only diagram that is widely used for construction, and it can be mapped with object-oriented languages. It is one of the most popular UML diagrams. Following are the purpose of class diagrams given below:
It analyses and designs a static view of an application.
It describes the major responsibilities of a system.
It is a base for component and deployment diagrams.
It incorporates forward and reverse engineering.
Benefits of Class Diagrams
It can represent the object model for complex systems.
It reduces the maintenance time by providing an overview of how an application is structured before coding.
It provides a general schematic of an application for better understanding.
It represents a detailed chart by highlighting the desired code, which is to be programmed.
It is helpful for the stakeholders and the developers.
Vital components of a Class Diagram
Upper Section: The upper section encompasses the name of the class. A class is a representation of similar objects that shares the same relationships, attributes, operations, and semantics. Some of the following rules that should be taken into account while representing a class are given below:
Capitalize the initial letter of the class name.
Place the class name in the center of the upper section.
A class name must be written in bold format.
The name of the abstract class should be written in italics format.
Middle Section: The middle section constitutes the attributes, which describe the quality of the class. The attributes have the following characteristics:
The attributes are written along with its visibility factors, which are public (+), private (-), protected (#), and package (~).
The accessibility of an attribute class is illustrated by the visibility factors.
A meaningful name should be assigned to the attribute, which will explain its usage inside the class.
Lower Section: The lower section contain methods or operations. The methods are represented in the form of a list, where each method is written in a single line. It demonstrates how a class interacts with data.
Relationships
In UML, relationships are of three types:
Dependency: A dependency is a semantic relationship between two or more classes where a change in one class cause changes in another class. It forms a weaker relationship.
In the following example, Student_Name is dependent on the Student_Id.
Generalization: A generalization is a relationship between a parent class (superclass) and a child class (subclass). In this, the child class is inherited from the parent class.
For example, The Current Account, Saving Account, and Credit Account are the generalized form of Bank Account.
Use-Case Diagrams
What is a use case diagram?
In the Unified Modeling Language (UML), a use case diagram can summarize the details of your system's users (also known as actors) and their interactions with the system. To build one, you'll use a set of specialized symbols and connectors. An effective use case diagram can help your team discuss and represent:
Scenarios in which your system or application interacts with people, organizations, or external systems
Goals that your system or application helps those entities (known as actors) achieve
The scope of your system
When to apply use case diagrams
A use case diagram doesn't go into a lot of detail—for example, don't expect it to model the order in which steps are performed. Instead, a proper use case diagram depicts a high-level overview of the relationship between use cases, actors, and systems. Experts recommend that use case diagrams be used to supplement a more descriptive textual use case.
UML is the modeling toolkit that you can use to build your diagrams. Use cases are represented with a labeled oval shape. Stick figures represent actors in the process, and the actor's participation in the system is modeled with a line between the actor and use case. To depict the system boundary, draw a box around the use case itself.
UML use case diagrams are ideal for:
Representing the goals of system-user interactions
Defining and organizing functional requirements in a system
Specifying the context and requirements of a system
Modeling the basic flow of events in a use case
Use case diagram components
To answer the question, "What is a use case diagram?" you need to first understand its building blocks. Common components include:
Actors: The users that interact with a system. An actor can be a person, an organization, or an outside system that interacts with your application or system. They must be external objects that produce or consume data.
System: A specific sequence of actions and interactions between actors and the system. A system may also be referred to as a scenario.
Goals: The end result of most use cases. A successful diagram should describe the activities and variants used to reach the goal.
UML Dynamic Modeling
Implementation Diagrams
The diagrams in this chapter allow you to model the physical environment of your system, and how its components will be deployed. PowerDesigner provides two types of diagrams for modeling your system in this way:
A component diagram represents your system decomposed into self-contained components or sub-systems. It can show the classifiers that make up these systems together with the artifacts that implement them, and exposes the interfaces offered or required by each component, and the dependencies between them. For more information, see Component Diagrams.
A deployment diagram allows you to represent the execution environment for a project. It describes the hardware on which each of your components will run and how that hardware is connected together. For more information, see Deployment Diagrams.
Component Diagrams
A component diagram is a UML diagram that provides a graphical view of the dependencies and generalizations among software components, including source code components, binary code components, and executable components.Deployment Diagrams
A deployment diagram is a UML diagram that provides a graphical view of the physical configuration of run-time elements of your system.Components (OOM)
A component is a physical, replaceable part of a system that packages implementation, conforms to and provides the realization of a set of interfaces. It can represent a physical piece of implementation of a system, like software code (source, binary or executable), scripts, or command files. It is an independent piece of software developed for a specific purpose but not a specific application. It may be built up from the class diagram and written from scratch for the new system, or it may be imported from other projects and third party vendors.Nodes (OOM)
A node is the main element of the deployment diagram. It is a physical element that represents a processing resource, a real physical unit, or physical location of a deployment (computer, printer, or other hardware units).Component Instances (OOM)
A component instance is an instance of a component that can run or execute on a node. Whenever a component is processed into a node, a component instance is created. The component instance plays an important role because it contains the parameter for deployment into a server.Files (OOM)
A file object can be a bitmap file used for documentation, or it can be a file containing text that is used for deployment into a server.Node Associations (OOM)
You can create associations between nodes, called node associations. They are defined with a role name and a multiplicity at each end. An association between two nodes means that the nodes communicate with each other, for example when a server is sending data to a backup server.
UML Extensibility
The Three UML Extensibility Mechanisms
The UML provides a standard language for writing software blueprints, but it is not possible for one closed language to ever be sufficient to express all possible nuances of all models across all domains across all time. For this reason, the UML is opened-ended, making it possible for you to extend the language in controlled ways.
UML defines three extensibility mechanisms to allow modelers to add extensions without having to modify the underlying modeling language. These three mechanisms are:
Stereotypes
Constraints
tagged values
Stereotypes
A stereotype extends the vocabulary of the UML, allowing you to create new kinds of building
blocks that are derived from existing ones but that are specific to your problem. They are used for classifying or marking the UML building blocks in order to introduce new building blocks that speak the language of your domain and that look like primitive, or basic, model elements.
For example, if you are working in a programming language, such as Java or C++, you will often want to model exceptions. In these languages, exceptions are just classes, although they are treated in very special ways. Typically, you only want to allow them to be thrown and caught, nothing else. You can make exceptions first-class citizens in your models, meaning that they are treated like basic building blocks, by marking them with an appropriate stereotype, as for the class Overflow as shown in the Figure below:
Model New types in UML
Another Example, an enumeration types, such as Coloroolean and Status, can be modeled as enumerations, with their individual values provided as attributes:
Model Special Relationship
A dependency can have a name, although names are rarely needed unless you want to use stereotypes to distinguish different flavors of dependencies. For example:
UML Meta-Model.
Meta-models
The Object Management Group (OMG) is in the business of specifying standards for object-oriented developers—modeling standards (like UML), middleware standards (like CORBA), data warehousing standards (like SAS), etc.
Here's my simplified summary of the OMG specifications:
There are three levels of abstraction in the OMG specifications:
M1 = Models (i.e., models created by UML users)
M2 = Meta-Models, M1 models are instances of M2 models = {UML, CWM}
M3 = Meta-Meta-Models, M2 models are instances of M3 models = {MOF}
The Meta Object Facility (MOF) was originally a CORBA type system. It is used for defining meta-models. MOF is to domain models what EBNF is to grammars. MOF could be used to define web services as well as OO concepts.
UML and CWM are M2 meta-models that instantiate M
No comments:
Post a Comment