Unified Modeling Language (UML)
computer science crazy|
Joined: Dec 2008
23-09-2008, 01:27 AM
The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software project and implimentations. Using the UML helps project and implimentation teams communicate, explore potential designs, and validate the architectural design of the software.
Large enterprise applications - the ones that execute core business applications, and keep a company going - must be more than just a bunch of code modules. They must be structured in a way that enables scalability, security, and robust execution under stressful conditions, and their structure - frequently referred to as their architecture - must be defined clearly enough that maintenance programmers can (quickly!) find and fix a bug that shows up long after the original authors have moved on to other project and implimentations. That is, these programs must be designed to work perfectly in many areas, and business functionality is not the only one (although it certainly is the essential core). Of course a well-designed architecture benefits any program, and not just the largest ones as we've singled out here.
We mentioned large applications first because structure is a way of dealing with complexity, so the benefits of structure (and of modeling and design, as we'll demonstrate) compound as application size grows large. Another benefit of structure is that it enables code reuse: Design time is the easiest time to structure an application as a collection of self-contained modules or components. Eventually, enterprises build up a library of models of components, each one representing an implementation stored in a library of code modules.
Modeling is the designing of software applications before coding. Modeling is an Essential Part of large software project and implimentations, and helpful to medium and even small project and implimentations as well. A model plays the analogous role in software development that blueprints and other plans (site maps, elevations, physical models) play in the building of a skyscraper. Using a model, those responsible for a software development project and implimentation's success can assure themselves that business functionality is complete and correct, end-user needs are met, and program design supports requirements for scalability, robustness, security, extendibility, and other characteristics, before implementation in code renders changes difficult and expensive to make.
Surveys show that large software project and implimentations 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 project and implimentations, 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.
Raising the Level of Abstraction:
Models help us by letting us work at a higher level of abstraction. A model may do this by hiding or masking details, bringing out the big picture, or by focusing on different aspects of the prototype. In UML 2.0, you can zoom out from a detailed view of an application to the environment where it executes, visualizing connections to other applications or, zoomed even further, to other sites. Alternatively, you can focus on different aspects of the application, such as the business process that it automates, or a business rules view. The new ability to nest model elements, added in UML 2.0, supports this concept directly.
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
Active In SP
Joined: Feb 2011
19-03-2011, 09:57 AM
OOAD-LAB-EX-NO-1.doc (Size: 143 KB / Downloads: 91)
To study the basic concepts of Unified Modeling Language
The heart of object-oriented problem solving is the construction of a model. The model abstracts the essential details of the underlying problem from its usually complicated real world. Several modeling tools are wrapped under the heading of the UML™, which stands for Unified Modeling Language™. The purpose of this course is to present important highlights of the UML.
• Unified Modeling Language.
• Set of notations and conventions used to describe and model an application.
• Universal language for modeling systems.
• Standard notation for OO modeling systems.
• Does not specify methodology to develop an application.
At the center of the UML are its nine kinds of modeling diagrams, which we describe here.
• Use case diagrams
• Class diagrams
• Object diagrams
• Sequence diagrams
• Collaboration diagrams
• State chart diagrams
• Activity diagrams
• Component diagrams
• Deployment diagrams
Some of the sections of this course contain links to pages with more detailed information. And every section has short questions. Use them to test your understanding of the section topic.
Why is UML important?
Let's look at this question from the point of view of the construction trade. Architects design buildings. Builders use the designs to create buildings. The more complicated the building, the more critical the communication between architect and builder. Blueprints are the standard graphical language that both architects and builders must learn as part of their trade.
Writing software is not unlike constructing a building. The more complicated the underlying system, the more critical the communication among everyone involved in creating and deploying the software. In the past decade, the UML has emerged as the software blueprint language for analysts, designers, and programmers alike. It is now part of the software trade. The UML gives everyone from business analyst to designer to programmer a common vocabulary to talk about software design.
The UML is applicable to object-oriented problem solving. Anyone interested in learning UML must be familiar with the underlying tenet of object-oriented problem solving -- it all begins with the construction of a model. A model is an abstraction of the underlying problem. The domain is the actual world from which the problem comes.Models consist of objects that interact by sending each other messages. Think of an object as "alive." Objects have things they know (attributes) and things they can do (behaviors or operations). The values of an object's attributes determine its state.
Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors (methods or functions) into a single distinct entity. Objects are instances of classes.
Use case diagrams:
Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how.
Use case diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system. Here is a scenario for a medical clinic.
"A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. "
A use case is a summary of scenarios for a single task or goal. An actor is who or what initiates the events involved in that task. Actors are simply roles that people or objects play. The picture below is a Make Appointment use case for the medical clinic. The actor is a Patient. The connection between actor and use case is a communication association (or communication for short).
Actors are stick figures. Use cases are ovals. Communications are lines that link actors to use cases.
A use case diagram is a collection of actors, use cases, and their communications. We've put Make Appointment as part of a diagram with four actors and four use cases. Notice that a single use case can have multiple actors.
Use case diagrams are helpful in three areas:
• Determining features (requirements). New use cases often generate new requirements as the system is analyzed and the design takes shape.
• Communicating with clients. Their notational simplicity makes use case diagrams a good way for developers to communicate with clients.
• Generating test cases. The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.
A Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static -- they display what interacts but not what happens when they do interact.
The class diagrams below models a customer order from a retail catalog. The central class is the Order. Associated with it are the Customer making the purchase and the Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order contains Order Details (line items), each with its associated Item.
UML class notation is a rectangle divided into three parts: class name, attributes, and operations. Names of abstract classes, such as Payment, are in italics. Relationships between classes are the connecting links.
Our class diagram has three kinds of relationships.
• association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes.
• aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. In our diagram, Order has a collection of OrderDetails.
• generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. Payment is a superclass of Cash, Check, and Credit.
An association has two ends. An end may have a role name to clarify the nature of the association. For example, an OrderDetail is a line item of each Order.
A navigability arrow on an association shows which direction the association can be traversed or queried. An OrderDetail can be queried about its Item, but not the other way around. The arrow also lets you know who "owns" the association's implementation; in this case, OrderDetail has an Item. Associations with no navigability arrows are bi-directional.
The multiplicity of an association end is the number of possible instances of the class associated with a single instance of the other end. Multiplicities are single numbers or ranges of numbers. In our example, there can be only one Customer for each Order, but a Customer can have any number of Orders.
Active In SP
Joined: Feb 2011
23-03-2011, 02:40 PM
Unified Modeling Language.docx (Size: 254.4 KB / Downloads: 71)
Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of software engineering. The standard is managed, and was created by, the Object Management Group.
UML includes a set of graphic notation techniques to create visual models of software-intensive systems.
The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software-intensive system under development. UML offers a standard way to visualize a system's architectural blueprints, including elements such as:
• business processes
• database schemas
• (logical) components
• programming language statements
• reusable software components.
UML combines techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies. UML has synthesized the notations of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language. UML aims to be a standard modeling language which can model concurrent and distributed systems. UML is a de facto industry standard, and is evolving under the auspices of the Object Management Group (OMG).
UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG. UML is extensible, offering the following mechanisms for customization: profiles and stereotypes.
Software development methods
UML is not a development method by itself; however, it was designed to be compatible with the leading object-oriented software development methods of its time (for example OMT, Booch method, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notations (for example OMT), and new methods have been created based on UML. The best known is IBM Rational Unified Process (RUP). There are many other UML-based methods like Abstraction Method, Dynamic Systems Development Method, and others, to achieve different objectives.
It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphic representation of a system's model. The model also contains documentation that drive the model elements and diagrams (such as written use cases).
UML diagrams represent two different views of a system model:
• Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams.
• Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams.
UML models can be exchanged among UML tools by using the XMI interchange format.
UML 2.2 has 14 types of diagrams divided into two categories. Seven diagram types represent structural information, and the other seven represent general types of behavior, including four that represent different aspects of interactions. These diagrams can be categorized hierarchically as shown in the following class diagram
UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams; this flexibility has been partially restricted in UML 2.0. UML profiles may define additional diagram types or extend existing diagrams with additional notations.
In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is allowed in a UML diagram.
Structure diagrams emphasize the things that must be present in the system being modeled. Since structure diagrams represent the structure they are used extensively in documenting the architecture of software systems.
• Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.
• Component diagram: describes how a software system is split up into components and shows the dependencies among these components.
• Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible.
• Deployment diagram: describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware.
• Object diagram: shows a complete or partial view of the structure of a modeled system at a specific time.
• Package diagram: describes how a system is split up into logical groupings by showing the dependencies among these groupings.
• Profile diagram: operates at the metamodel level to show stereotypes as classes with the <<stereotype>> stereotype, and profiles as packages with the <<profile>> stereotype. The extension relation (solid line with closed, filled arrowhead) indicates what metamodel element a given stereotype is extending.
Behavior diagrams emphasize what must happen in the system being modeled. Since behavior diagrams illustrate the behavior of a system, they are used extensively to describe the functionality of software systems.
• Activity diagram: describes the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.
• UML state machine diagram: describes the states and state transitions of the system.
• Use case diagram: describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.
Interaction diagrams, a subset of behaviour diagrams, emphasize the flow of control and data among the things in the system being modeled:
• Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.
• Interaction overview diagram: provides an overview in which the nodes represent communication diagrams.
• Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.
• Timing diagrams: a specific type of interaction diagram where the focus is on timing
The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.
Illustration of the Meta-Object Facility
The Object Management Group (OMG) has developed a metamodeling architecture to define the Unified Modeling Language (UML), called the Meta-Object Facility (MOF). The Meta-Object Facility is a standard for model-driven engineering, designed as a four-layered architecture, as shown in the image at right. It provides a meta-meta model at the top layer, called the M3 layer. This M3-model is the language used by Meta-Object Facility to build metamodels, called M2-models. The most prominent example of a Layer 2 Meta-Object Facility model is the UML metamodel, the model that describes the UML itself. These M2-models describe elements of the M1-layer, and thus M1-models. These would be, for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe runtime instance of the system.
Beyond the M3-model, the Meta-Object Facility describes the means to create and manipulate models and metamodels by defining CORBA interfaces that describe those operations. Because of the similarities between the Meta-Object Facility M3-model and UML structure models, Meta-Object Facility metamodels are usually modeled as UML class diagrams. A supporting standard of the Meta-Object Facility is XMI, which defines an XML-based exchange format for models on the M3-, M2-, or M1-Layer.
Joined: Jul 2011
26-01-2012, 04:14 PM
Unified Modeling Language
presentation.pptx (Size: 712.14 KB / Downloads: 40)
WHAT IS UML?
The Unified Modeling Language (UML) is a
standard language for specifying, visualizing,
constructing, and documenting the artifacts of
software systems, as well as for business modeling
and other non-software systems.
The UML uses mostly graphical notations to
express the design of software project and implimentations.
Why Use UML?
To improve the quality.
To automate the production of software.
To reduce cost and time-to-market.
To manage the complexity of systems as they
increase in scope and scale.
To solve recurring architectural problems, such as
physical distribution, concurrency, replication,
security, load balancing and fault tolerance.
Use – Case Diagrams:
An actor represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents some action the user might perform in order to complete a task.
Active In SP
Joined: Feb 2012
03-03-2012, 02:44 PM
Unified Modeling Language (UML)
02-2_Daniels_Tutorial-UML_Components.pdf (Size: 223.36 KB / Downloads: 59)
Unified Modeling Language
• The UML is a standardised language for
describing the structure and behaviour of
• UML emerged from the world of objectoriented
• UML has a set of notations, mostly graphical
• There are tools that support some parts of
Component standard features
– defined set of services that support the software
– set of rules that must be obeyed in order to take
advantage of the services
• Simple programming model, no need to
design/know about the infrastructure
• Services include:
– remote access, transactions, persistent storage, security
– typically use services by configuring not programming
Management and Development Processes
• Management Processes
– Schedule work and plan deliveries
– Allocate resources
– Monitor progress
– Control risk
• Development Processes
– Create working software from requirements
– Focus on software development artifacts
– Described independently of the management process
– Defines ordering constraints and dependencies
– Organized into Workflows
• We need to decide what components we want, and
which interfaces they will support
• These are fundamental architectural decisions
• Business components:
– they support the business interfaces
– remember: components define the unit of development
• The starting assumption is one component spec
per business interface
Active In SP
Joined: Feb 2012
28-03-2012, 11:29 AM
UML ( Unified Modeling Langauage)
compt topic ATM.docx (Size: 164.53 KB / Downloads: 29)
• To represent complete systems (instead of only the software portion) using object-oriented concepts
• To establish an explicit coupling between concepts and executable code
• To take into account the scaling factors that are inherent to complex and critical systems
• To creating a modeling language usable by both humans and machines
UML defines several models for representing systems:
• The class model captures the static structure
• The state model expresses the dynamic behavior of objects.
• The use case model describes the requirements of the user.
• The interaction model represents the scenarios and messages flows
• The implementation model shows the work units
• The deployment model provides details that pertain to process allocation
UML defines nine different types of diagram:
1. Use case diagrams: represent the functions of a system from the user's point of view.
2. Sequence diagrams: are a temporal representation of objects and their interactions.
3. Collaboration diagrams: spatial representation of objects, links, and interactions.
4. Object diagrams :represent objects and their relationships and correspond to simplified collaboration diagrams that do not represent message broadcasts.
5. Class diagrams represent the static structure in terms of classes and relationships
6. Statechart diagrams: represent the behavior of a class in terms of states at run time.
7. Activity diagrams: represent the behavior of an operation as a set of actions
8. Component diagrams: represent the physical components of an application
9. Deployment diagrams: represent the deployment of components on particular pieces of hardware
Use Case Specification:
• A flow of events document is created for each use cases
• Written from an actor point of view
• Details what the system must provide to the actor when the use cases is executed
• Typical contents
o How the use case starts and ends
o Normal flow of events
o Alternate flow of events
o Exceptional flow of events
Joined: Apr 2012
21-05-2012, 03:49 PM
Simple Unified Modeling Language (UML)
Simple UML.ppt (Size: 51 KB / Downloads: 65)
What is UML?
UML stands for Unified Modeling Language
UML is a diagramming language designed for Object-Oriented programming
UML can be used to describe:
the organization of a program
how a program executes
how a program is used
how a program is deployed over a network
Design Patterns describe the higher-level organization of solutions to common problems
Design Patterns are a current hot topic in O-O design
UML is always used for Design Patterns
Design Patterns are used to describe refactorings
We will discuss some Design Patterns later on in this course
UML is a big, complicated diagramming language
UML comprises at least seven or eight different kinds of diagrams
This talk will cover just a tiny bit of one kind of diagram, the class diagram
A class diagram is often all that is needed to describe a particular Design Pattern
Rational Rose is the “real world” standard; full round-trip code generation
Recently acquired by IBM (right under Microsoft’s nose!)
Together (from Borland) is a lot like Rational Rose
I haven’t used it in about three years (since before Borland bought it from TogetherSoft)
ArgoUML looks interesting (and is open source)
BlueJ, of course, displays simple UML diagrams
Drawing programs with UML support
Visio is a Microsoft tool
Dia is a freeware clone of Visio.
Joined: Apr 2012
08-08-2012, 01:28 PM
uml.pdf (Size: 38.76 KB / Downloads: 113)
What is a UML Class Diagram?
Class diagrams are the backbone of almost every object-oriented method including
UML. They describe the static structure of a system.
Basic Class Diagram Symbols and Notations
Classes represent an abstraction of entities with common characteristics. Associations
represent the relationships between classes.
Illustrate classes with rectangles divided
into compartments. Place the name of the
class in the first partition (centered,
bolded, and capitalized), list the attributes
in the second partition, and write
operations into the third.
Composition and Aggregation
Composition is a special type of
aggregation that denotes a strong
ownership between Class A, the whole, and
Class B, its part. Illustrate composition with
a filled diamond.
Use a hollow diamond to represent a
simple aggregation relationship, in which
the "whole" class plays a more important
role than the "part" class, but the two
classes are not dependent on each other.
The diamond end in both a composition
and aggregation relationship points toward
the "whole" class or the aggregate.
Generalization is another name for
inheritance or an "is a" relationship. It
refers to a relationship between two
classes where one class is a specialized
version of another. For example, Honda is
a type of car. So the class Honda would
have a generalization relationship with the
In real life coding examples, the difference
between inheritance and aggregation can
be confusing. If you have an aggregation
relationship, the aggregate (the whole) can
access only the PUBLIC functions of the
part class. On the other hand, inheritance
allows the inheriting class to access both
the PUBLIC and PROTECTED functions of