Download Unified Modeling Language (UML): A Comprehensive Guide for Software Development and more Lecture notes Object Oriented Analysis and Design in PDF only on Docsity!
The UML is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML gives you a standard way to write a system's blueprints , covering conceptual things , such as business processes and system functions, as well as concrete things, such as classes written in a specific programming language, database schemas, and reusable software components.
Model
A model is a simplification of reality. A model provides the blueprints of a
system. A model may be structural , emphasizing the organization of
the system , or it may be behavioral, emphasizing the dynamics of the
system.
Why do we build model
We build models so that we can better understand the system we are developing.
Through modeling, we achieve four aims.
- Models help us to visualize a system as it is or as we want it to b e.
- Models permit us to specify the structure or behavior of a system.
- Models give us a template that guides us in constructing a system.
- Models document the decisions we have made.
We build models of complex systems because we cannot comprehend such a system in its entirety.
Principles of Modeling
There are four basic principles of model
- The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped.
- Every model may be expressed at different levels of precision.
- The best models are connected to reality.
- No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models.
Object Oriented Modeling
In software, there are several ways to approach a model. The two most common ways are
- Algorithmic perspective
Object-Oriented System Analysis and Modeling
CHAPTER THREE
UML class diagrams, Object-Oriented Analysis, Formal Modeling
using OCL, Building Class Diagrams to Model various Domains
- Object-oriented perspective
Algorithmic Perspective
The traditional view of software development takes an algorithmic perspective. In this approach, the main building block of all software is the
procedure or function. This view leads developers to focus on issues of control and the decomposition of larger algorithms into smaller ones. As requirements change and the system grows, systems built with an algorithmic focus turn out to be very hard to maintain.
Object-oriented perspective
The contemporary (modern) view of software development takes an object-oriented perspective. In this approach, the main building block of all software systems is the object or class. A class is a description of a set of common objects. Every object has identity , state , and behavior. Object-oriented development provides the conceptual foundation for assembling systems out of components using technology such as Java Beans or COM+.
An Overview of UML
The Unified Modeling Language is a standard language for writing software blueprints. The UML may be used to visualize, specify, construct, and document the artifacts of a software- intensive system. The UML is appropriate for modeling systems ranging from enterprise information systems to distributed Web-based applications and even to hard real time embedded systems. It is a very expressive language , addressing all the views needed to develop and then deploy such systems.
The UML is a language for Visualizing Specifying Constructing Documenting
Visualizing The UML is more than just a bunch of graphical symbols. Rather, behind each symbol in the UML notation is a well-defined semantics. In this manner, one developer can write a model in the UML, and another developer, or even another tool, can interpret that model unambiguously
Specifying means building models that are precise, unambiguous, and complete.
An interface therefore describes the externally visible behavior of that element. An interface might represent the complete behavior of a class or component or only a part of that behavior.
An interface is rendered as a circle together with its name. An interface rarely stands alone. Rather, it is typically attached to the class or component that realizes the interface
Collaboration defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that's bigger than the sum of all the elements. Therefore, collaborations have structural, as well as behavioral, dimensions. A given class might participate in several collaborations.
Graphically, collaboration is rendered as an ellipse with dashed lines, usually including only its name
Usecase Use case is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor Use case is used to structure the behavioral things in a model. A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name
Active class is just like a class except that its objects represent elements whose behavior is concurrent with other elements. Graphically, an active class is rendered just like a class, but with heavy lines, usually including its name, attributes, and operations
Component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Graphically, a component is rendered as a rectangle with tabs
Node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability. Graphically, a node is rendered as a cube, usually including only its name
Behavioral Things are the dynamic parts of UML models. These are the verbs of a model, representing behavior over time and space. In all, there are two primary kinds of behavioral things Interaction state machine
Interaction Interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose An interaction involves a number of other elements, including messages, action sequences and links Graphically a message is rendered as a directed line, almost always including the name of its operation
State Machine State machine is a behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events State machine involves a number of other elements, including states, transitions, events and activities Graphically, a state is rendered as a rounded rectangle, usually including its name and its substates
Grouping Things:-
- are the organizational parts of UML models. These are the boxes into which a model can be decomposed 2. There is one primary kind of grouping thing, namely, packages.
Package:- A package is a general-purpose mechanism for organizing elements into groups. Structural things , behavioral things , and even other grouping things may be placed in a package Graphically, a package is rendered as a tabbed folder, usually including only its name and, sometimes, its contents
Annotational things are the explanatory parts of UML models. These are the comments you may apply to describe about any element in a model.
A note is simply a symbol for rendering constraints and comments attached to an element or a collection of elements.
Sequence diagram Collaboration diagram Statechart diagram Activity diagram Component diagram Deployment diagram
Class diagram A class diagram shows a set of classes , interfaces , and collaborations and their relationships. Class diagrams that include active classes address the static process view of a system.
Object diagram Object diagrams represent static snapshots of instances of the things found in class diagrams These diagrams address the static design view or static process view of a system An object diagram shows a set of objects and their relationships
Use case diagram A use case diagram shows a set of use cases and actors and their relationships Use case diagrams address the static use case view of a system. These diagrams are especially important in organizing and modeling the behaviors of a system.
Interaction Diagrams Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams
Interaction diagrams address the dynamic view of a
system A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take one and transform it into the other
StateChart diagram A statechart diagram shows a state machine, consisting of states, transitions, events, and activities Statechart diagrams address the dynamic view of a system They are especially important in modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered behavior of an object
Activity diagram An activity diagram is a special kind of a statechart diagram that shows the flow from activity to activity within a system Activity diagrams address the dynamic view of a system
They are especially important in modeling the function of a system and emphasize the flow of control among objects
Component diagram A component diagram shows the organizations and dependencies among a set of components. Component diagrams address the static implementation view of a system They are related to class diagrams in that a component typically maps to one or more classes, interfaces, or collaborations
Deployment diagram A deployment diagram shows the configuration of run-time processing nodes and the components that live on them Deployment diagrams address the static deployment view of an architecture
Architecture
A system's architecture is perhaps the most important artifact that can be used to manage these different viewpoints and so control the iterative and incremental development of a system throughout its life cycle.
Architecture is the set of significant decisions about
- The organization of a software system
- The selection of the structural elements and their interfaces by which the system is composed
- Their behavior, as specified in the collaborations among those elements
- The composition of these structural and behavioral elements into progressively larger subsystems
- The architectural style that guides this organization: the static and dynamic elements and their interfaces, their collaborations, and their composition.
Software architecture is not only concerned with structure and behavior, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and trade-offs, and aesthetic concerns.
Vocabulary System Assembly Functionality Configuration Mgmt
Behavior
Performance System topology Scalability Distribution delivery Throughput Installation
Modeling a System's Architecture
Design View
Process View
Implementation View
Deployment view
Use case view
Every class must have a name that distinguishes it from other classes. A name is a textual string that name alone is known as a simple name; a path name is the class name prefixed by the name of the package in which that class lives.
Simple Name Path Name
Attributes An attribute is a named property of a class that describes a range of values that instances of the property may hold. A class may have any number of attributes or no attributes at all. An attribute represents some property of thing you are modeling that is shared by all objects of that class You can further specify an attribute by stating its class and possibly a default initial value
Attributes and Their Class
Operations An operation is the implementation of a service that can be requested from any object of the class to affect behavior. A class may have any number of operations or no operations at all Graphically, operations are listed in a compartment just below the class attributes You can specify an operation by stating its signature, covering the name, type, and default value of all parameters and a return type
Organizing Attributes and Operations To better organize long lists of attributes and operations, you can also prefix each group with a descriptive category by using stereotypes
Responsibilities A Responsibility is a contract or an obligation of a class When you model classes, a good starting point is to specify the responsibilities of the things in your vocabulary. A class may have any number of responsibilities, although, in practice, every well-structured class has at least one responsibility and at most just a handful. Graphically, responsibilities can be drawn in a separate compartment at the bottom of the class icon
Common Modeling Techniques
Modeling the Vocabulary of a System You'll use classes most commonly to model abstractions that are drawn from the problem you are trying to solve or from the technology you are using to implement a solution to that problem. They represent the things that are important to users and to implementers
To model the vocabulary of a system
o Identify those things that users or implementers use to describe the problem or solution. o Use CRC cards and use case-based analysis to help find these abstractions. o For each abstraction, identify a set of responsibilities. o Provide the attributes and operations that are needed to carry out these responsibilities for each class.
Modeling the Distribution of Responsibilities in a System
Once you start modeling more than just a handful of classes, you will want to be sure that your abstractions provide a balanced set of responsibilities. To model the distribution of responsibilities in a system
o Identify a set of classes that work together closely to carry out some behavior. o Identify a set of responsibilities for each of these classes. o Look at this set of classes as a whole, split classes that have too many responsibilities into smaller abstractions, collapse tiny classes that have trivial responsibilities into larger ones, and reallocate
Dependencies
Generalization
o A generalization is a relationship between a general thing (called the super class or parent) and a more specific kind of that thing (called the subclass or child). o Generalization means that the child is substitutable for the parent. A child inherits the properties of its parents, especially their attributes and operations o An operation of a child that has the same signature as an operation in a parent overrides the operation of the parent; this is known as polymorphism. o Graphically generalization is rendered as a solid directed line with a large open arrowhead, pointing to the parent
Generalization
Association
o An association is a structural relationship that specifies that objects of one thing are connected to objects of another o An association that connects exactly two classes is called a binary association o An associations that connect more than two classes; these are called n-ary associations. o Graphically, an association is rendered as a solid line connecting the same or different classes. o Beyond this basic form, there are four adornments that apply to associations
Name o An association can have a name, and you use that name to describe the nature of the relationship
Role o When a class participates in an association, it has a specific role that it plays in that relationship; o The same class can play the same or different roles in other associations. o An instance of an association is called a link
Role Names Multiplicity o In many modeling situations, it's important for you to state how many objects may be connected across an instance of an association o This "how many" is called the multiplicity of an association's role o You can show a multiplicity of exactly one (1), zero or one (0..1), many (0..), or one or more (1..). You can even state an exact number (for example, 3).
Multiplicity Aggregation o Sometimes, you will want to model a "whole/part" relationship, in which one class represents a larger thing (the "whole"), which consists of smaller things (the "parts"). o This kind of relationship is called aggregation, which represents a "has-a" relationship, meaning that an object of the whole has objects of the part o Aggregation is really just a special kind of association and is specified by adorning a plain association with an open diamond at the whole end
Aggregation
Common Modeling Techniques
Modeling Simple Dependencies
Given a generalization relationship between two classes, the child inherits from its parent but the parent has no specific knowledge of its children. Dependency and generalization relationships are one-sided. Associations are, by default, bidirectional; you can limit their direction Given an association between two classes, both rely on the other in some way, and you can navigate in either direction An association specifies a structural path across which objects of the classes interact.
To model structural relationships
For each pair of classes, if you need to navigate from objects of one to objects of another, specify an association between the two. This is a data- driven view of associations.
For each pair of classes, if objects of one class need to interact with objects of the other class other than as parameters to an operation, specify an association between the two. This is more of a behavior-driven view of associations.
For each of these associations, specify a multiplicity (especially when the multiplicity is not *, which is the default), as well as role names (especially if it helps to explain the model).
If one of the classes in an association is structurally or organizationally a whole compared with the classes at the other end that look like parts, mark this as an aggregation by adorning the association at the end near the whole
Structural Relationships
Examples:
1. School model Class Diagram:
2. Hospital Model Class Diagram
3.ATM Model Class Diagram
