Advanced O-O Software Engineering

UML Modeling 2 Tutorial

By

Nick Leuci

Los Angeles,  CA

[email-masked]

Copyright  ©  2018              All Rights Reserved

UML Notation (2):  Overview

The Unified Modeling Language (UML) 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.  A modeling language is a language whose vocabulary and rules focus on the conceptual and physical representation of a system.

The UML is more than a group of graphical symbols.  Rather, behind each symbol in the UML notation is set of well-defined semantics.  Each graphical symbol (visual element) is itself an object in the metamodel underlying the repository.

The UML is NOT a visual programming language, but its models can be directly connected to a variety of programming languages.  This tutorial uses Java to illustrate programming language issues, but any object-oriented language would apply, such as C#, VB.Net, C++, Ada-95, etc.  Note that UML itself is language independent, except that any target language must be Object-Oriented.

Also, note that some UML modeling (drawing) tools can generate the target language source code for the classes, like IBM Rational Rose, MS Visio for Enterprise Architects, etc.  These tools can also be used to reverse engineer changes in the classes back into the UML model repository.  This process is called ‘Round-Trip’ or Bidirectional Software Engineering, in the general purview of Object-Oriented Software Engineering.

This tutorial focuses solely on UML modeling elements and diagrams types, and their uses in a software development workflow.

UML Notation (2):  Overview

The Unified Modeling Language (UML) is a summation of all the major trends in OOA/D/P.  It synthesizes and refines what has come before it.  Its major new achievement is in establishing a consensus standard for both a notation and methodology in which repository-based tools can be used.

The early indication is that this effort at standardization will succeed, advancing Object technology dramatically.

UML has several high level core features:

·     Views:  an aspect (perspective) of a modeled system (5)

·     Diagrams:  graphs describing the contents of a view (9)

·     Model Elements:  the concepts of the components

·     General Mechanisms:  extra comments or semantics

UML Notation (2):  Overview

UML supports forward code generation from a model in a repository to text (source code), and also reverse engineering from text source back to the graphical model.  This yields round-trip engineering, meaning the ability to work in either a graphical (model) or a textual view (source), while the UML tool (i.e.: Rose) keeps the two views consistent.

ARTIFACTS

An artifact is anything that goes into or comes out of a software development process.  Typically, these are documents, files, drawings, etc.

Such artifacts are not only the deliverables of a project, they are also critical in controlling, measuring, and communicating about a system during its development and after its deployment.

UML Notation (2):  Overview

A software group typically makes many artifacts, including:

·     Requirements

·     Architecture

·     Design

·     Source code

·     Project plans

·     Tests

·     Prototypes

·     Releases

The UML addresses the documentation of a system's architecture and all of its details.  The UML also provides a language for expressing requirements and for tests.  Finally, the UML provides a language for modeling the activities of project planning and release management.

UML Notation (2):  Model Elements

The diagram types (described later in this presentation) in UML use atomic components to provide users with the means to draw models.

These atomic components are the core concepts or ‘Model Elements’ in UML:  classes, objects, interfaces, states, modules, notes, use cases, etc., as shown in the following slide.  The model elements form the basis of the UML ‘Visual Vocabulary’.

Note that each Model Element is also associated with a UML View (described later in this presentation).  Some Model Elements can exist in more than one diagram type and view, but this is based on rules within the repository.  Other Model Elements include relationships, messages, actions and stereotypes.

UML Notation (2):  Model Elements

|

UML Notation (2):  Model Elements

Relationships are also UML Model Elements, and they are summarized in the next slide.

Relationships are used to connect other Model Elements with each other.  Common relationship types include:

·     Association:  connects elements and link instances

·     Generalization:  an inheritance relationship, one element is a ‘specialization’ of another element

·     Dependency:  one element depends in some way on another element

·     Aggregation:  a composition relationship, one element contains another element

UML Notation (2):  Model Elements

Examples of Relationships in UML:

|

UML Notation (2):  Visual Vocabulary

The visual vocabulary of the UML has three building blocks:

·     Things – the first abstractions in a model

·     Relationships – elements that tie things together

·     Diagrams – elements that group collections of things

Things in the UML

There are four kinds of things in the UML, each with their own graphical elements and underlying semantics:

1.            Structural things

2.            Behavioral things

3.            Grouping things

4.            Annotational things

UML Notation (2):  Visual Vocabulary

Structural Things

Structural things are the nouns of UML models.  These are the mostly static parts of a model, representing elements that are either conceptual or physical.

There are seven kinds of structural things:

1.                        Structural thing::  class

2.                        Structural thing::  interface

3.                        Structural thing::  collaboration

4.                        Structural thing::  use case

5.                        Structural thing::  active classes

6.                        Structural thing::  components

7.                        Structural thing::  nodes

UML Notation (2):  Visual Vocabulary

Structural thing::  class

A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.  A class implements one or more interfaces.  Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations:

|

UML Notation (2):  Visual Vocabulary

Class Diagrams can be rendered with template specifications and type bindings in UML.  Since Java does not currently support templates, these features are unused with the JDK:

|

UML Notation (2):  Visual Vocabulary

Structural thing::  interface

An interface is a collection of operations that specify a service of a class or component.  An interface therefore describes the externally visible behavior of that element.  An interface defines a set of operation specifications (signatures) but never a set of operation implementations.  Graphically, 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:

|

UML Notation (2):  Visual Vocabulary

Structural thing::  collaboration

A collaboration defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that is 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.  These collaborations represent the implementation of patterns that make up a system.  Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name:

|

UML Notation (2):  Visual Vocabulary

Structural thing::  use cases

A 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.  A 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:

|

UML Notation (2):  Visual Vocabulary

Structural thing::  active classes

An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity.  An 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:

|

UML Notation (2):  Visual Vocabulary

Structural thing::  components

A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces.  There are many different kinds of deployment components, such as CORBA or Java Beans, as well as components that are artifacts of the development process (i.e.: source files).  A component represents the physical packaging of logical elements (classes, interfaces, and collaborations, etc.).  Graphically, a component is rendered as a rectangle with tabs, usually including only its name:

|

UML Notation (2):  Visual Vocabulary

Structural thing::  nodes

A 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.  A set of components may reside on a node and may also migrate from node to node.  Graphically, a node is rendered as a cube, usually including only its name:

|

UML Notation (2):  Visual Vocabulary

Behavioral Things:  Interactions

Behavioral things are the dynamic parts of UML models, the verbs of a model, representing behavior over time and space.  There are two main behavioral things:  interactions and states.  Semantically, these elements are usually connected to various structural elements, primarily classes, collaborations, and objects.  An interaction is a behavior comprising a set of messages exchanged among objects within a context for a specific purpose.  The behavior among objects or in one operation may be specified with an interaction.  An interaction involves other elements: messages, action sequences (behavior invoked by a message), and links (connection between objects).  Graphically, a message is drawn as a directed line, usually including the name of its operation:

|

UML Notation (2):  Visual Vocabulary

Behavioral Things:  States

A 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.  The behavior of an individual class or a collaboration of classes may be specified with a state machine.  A state machine involves a number of other elements, including states, transitions (the flow from state to state), events (things that trigger a transition), and activities (the response to a transition).  Graphically, a state is rendered as a rounded rectangle, usually including its name and its substates, if any:

|

UML Notation (2):  Visual Vocabulary

Grouping Things:  Packages

Grouping things are the organizational parts of UML models.  These are the boxes into which a model can be decomposed.  There is one kind of grouping thing:  packages.  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.  Unlike components (which exist at run time), a package is purely conceptual (it exists only at development time).  Graphically, a package is rendered as a tabbed folder, usually including only its name and, sometimes, its contents:

|

UML Notation (2):  Visual Vocabulary

Annotational Things:  Notes

Annotational things are the explanatory parts of UML models.  These are the comments to describe, illuminate, and remark about any element in a model.  There is one primary kind of annotational thing, called a note.  A note is simply a symbol for rendering constraints and comments attached to an element or a collection of elements.  Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment:

|

UML Notation (2):  Visual Vocabulary

Annotational Things:  Notes

Comments can be attached, via a dotted line, to any Model Element, as shown below.  These comments are called Notes, and they can become an effective part of the documentation of a system.  A Specification is an actual value of a Model Element that is visible in a property sheet, not in a diagram (i.e.:  concurrency, etc.).

|

UML Notation (2):  Visual Vocabulary

Adornments

UML has a group of General Mechanisms to add additional information to diagrams.  These include Adornments, Notes, and Specifications.  Graphical Adornments can be attached to Model Elements in diagrams so they can add semantics.  When an element represents a type, the name is boldfaced;  when the name is underlined, this represents an instance, as shown below.  Labeling Multiplicity is also an adornment.

|

UML Notation (2):  Visual Vocabulary

Relationships in the UML

There are four kinds of relationships in the UML:

1.                        Dependency

2.                        Association

3.                        Generalization

4.                        Realization

These relationships are the basic relating elements of the UML, essential to write well-formed models.  A dependency is a semantic relationship between two things in which a change to one thing (the independent thing) may affect the semantics of the other thing (the dependent thing).  Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally including a label:

|

UML Notation (2):  Visual Vocabulary

Association Relationships

An association is a structural relationship that describes a set of links, or connections among objects.  The most common relationship is the ‘use-a’ or using relation.  Graphically, an association is rendered as a solid line, possibly directed or including a label, and often with other adornments, such as multiplicity (next slide) and role names:

|

UML Notation (2):  Visual Vocabulary

Association Multiplicities (Cardinality Adornments):

|

UML Notation (2):  Visual Vocabulary

Aggregation Association

Aggregation is a special kind of association, representing a structural ‘has-a’ relationship between a whole and its parts, which may include composition or ordering constraints:

|

UML Notation (2):  Visual Vocabulary

Generalization Association

Generalization is the ‘is-a’ relation in which objects of the specialized subtype (child) are substitutable for objects of the generalized supertype (parent).  The child shares the structure and the behavior of the parent.  Generalization is drawn as a line with an empty arrow aiming to the parent:

|

UML Notation (2):  Visual Vocabulary

Associations can have additional adornments and semantics, including qualified association, navigabilities, and dependencies:

|

UML Notation (2):  Visual Vocabulary

Realization Association

A realization is a semantic relationship between classifiers, where one classifier specifies a contract that another classifier guarantees to carry out.  Contracts are from a very early Object-Oriented methodology:  Class-Responsibility-Collaboration (CRC).

Realization relationships occur in two places:  between interfaces and the classes or components that realize them, and between use cases and the collaborations that realize them.  Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship:

|

UML Notation (2):  Extending UML

Stereotypes

UML can be extended or adapted to a specific method, organization, or user by the use of facilities such as stereotypes, tagged values, and constraints.  A Stereotype defines a new Model Element based on an existing Model Element, plus some extra semantics.  A Stereotype has all of the underlying properties and relationships of the underlying Model Element it is based on.

|

UML Notation (2):  Extending UML

Tagged Pairs

Model Elements can have named properties that have values;  these name-value pairs are called tagged values, as shown below.

Some properties are internal, some external;  properties (attributes) have a variety of purposes.  Regardless, they can all be tagged.

|

UML Notation (2):  Extending UML

Constraints

A Constraint is a restriction on a Model Element.  In the Class Diagram below, Person objects must be older than 60 to participate in the Senior Citizen Group association.

|

UML Notation (2):  Views

Like OMT, Views show different aspects of a modeled system.  Each view is an abstraction of the whole model, consisting of a set of related diagrams to convey the dimension of the view.  Views also link the modeling language to the method/process chosen for development.

As shown in the next slide, there are Five Views in UML:

1.                        Use-Case View:  shows external ‘actors’ view

2.                        Logical View:  shows static structure & dynamic behavior

3.                        Component View:  shows code components organization

4.                        Concurrency View:  shows system concurrency

5.                        Deployment View:  shows physical implementation

UML Notation (2):  Views

|

UML Notation (2):  Use Case View

The Use Case View describes functionality the system should deliver, as perceived by external actors, who interact with the system.  An actor could be a user, customer, or another system.

The Use Case View typically consists of Use Case Diagrams or Activity Diagrams.  The Use Case View is central, since it relates directly to requirements and it drives everything else.

The Use Case View is also used for testing and validation purposes.

The ‘Use Case Driven Approach’ to Software Engineering was developed by Ivar Jacobson of Rational.  We will revisit this core component in great detail.

UML Notation (2):  Logical View

The Logical View describes how system functionality is organized.  Where the Use Case View is from an external perspective, the Logical View is from an internal perspective.  The Logical View is unimportant to ‘actors’, but it is the lifeblood of developers.

The Logical View contains both the static structure (i.e.:  OMT Object Model) and the dynamic collaborations (i.e.:  OMT Dynamic Model).  It describes properties, methods, and events (‘messages’).

The static structure is described in Class and Object Diagrams.  The dynamic modeling is described in State, Sequence, Collaboration and Activity Diagrams.

UML Notation (2):  Component View

The Component View details the implementation modules and their dependencies.  It is an internal view meant for developers;  it has overlaps with both the OMT Object and Functional Model.

The Component View consists of Component Diagrams.  Components are different types of code modules, and they are shown with their structure and dependencies.

The Component View comes into heavy use during detailed design and implementation in the Software Engineering Life Cycle.

UML Notation (2):  Concurrency View

The Concurrency View focuses on seeing the system as processes and processors.  This aspect, although a non-functional (non-internal) property of the system, shows resource allocation, parallel execution, and the handling of synchronous and asynchronous events, and especially communication and synchronization of threads in multi-threaded environments.  This is the area of O-O technology that is the least standardized, with many proprietary aspects.

The Concurrency View is for developers and integrators, and it consists of dynamic (State, Sequence, Collaboration, and Activity) diagrams, as well as implementation (Component and Deployment) diagrams.

UML Notation (2):  Deployment View

The Deployment Views shows the physical architecture and deployment of the system, including the underlying hardware and network infrastructure, and how everything interconnects.

The Deployment View is for developers, integrators, and testers, and it consists of Deployment Diagrams.

The Deployment View also includes mappings showing how components are deployed in the physical architecture (i.e.:  which programs or modules execute on which computers or networks, etc.).

UML Notation (2):  Diagrams

A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships).  You draw diagrams to visualize a system from different perspectives, so a diagram is a projection into a system.

For all but the most trivial systems, a diagram represents an elided view of the elements that make up a system.  The same element may appear in all diagrams, only a few diagrams (the most common case), or in no diagrams at all (a very rare case).  In theory, a diagram may contain any combination of things and relationships.

UML Notation (2):  Diagrams

Like OMT, diagrams are graphs created with a drawing tool that show how components collaborate or interconnect. However, a small number of common combinations arise, which are consistent with the five views that comprise the architecture of a software-intensive system.  For this reason, the UML includes nine such diagrams:  They are:

1.                        Use Case Diagrams

2.                        Class Diagrams

3.                        Object Diagrams

4.                        State (or Statechart) Diagrams

5.                        Sequence Diagrams

6.                        Collaboration Diagrams

7.                        Activity Diagrams

8.                        Component Diagrams

9.                        Deployment Diagrams

UML Notation (2):  Use Case Diagram

The Use Case Diagram shows the external ‘actors’ of a system and how they interact with the system, as shown in the next slide.  As in OMT, actors can generate inputs and receive outputs.

Actors can be shown as stick figures, representing a human user interface, or they can be other systems.  Each Use Case Diagram shows a ‘Use Case’, a description of specific functionality or usage the system provides.  The description is usually a text property of the use case object, but it can also be described in an Activity Diagram.

Use Cases flow from Requirements;  they NEVER show how the needed functionality is to be designed or implemented.

UML Notation (2):  Use Case Diagram

|

UML Notation (2):  Use Case Diagram

A use case diagram shows a set of use cases and actors (a special kind of class) 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.

|

UML Notation (2):  Diagrams

Class Diagram

A class diagram shows a set of classes, interfaces, and collaborations and their relationships.  These diagrams are the most common diagrams found in modeling object-oriented systems.  Class diagrams address the static design view of a system.  Class diagrams that include active classes address the static process view of a system.

Object Diagram

An object diagram shows a set of objects and their relationships.  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 as do class diagrams, but from the perspective of real or prototypical cases.

UML Notation (2):  Class Diagram

The Class Diagram depicts the static structure of classes in the system.  Remember that classes are ‘nouns’, the irreducible, necessary ‘things’ in a system.  The UML Class Diagram, shown in the following slide, is very similar in meaning and depiction to the Object Model in OMT.

Class Diagrams show properties, methods, associations, multiplicities, dependencies, generalization (inheritance) and aggregation (composition).

This diagram is considered static in that the internal structure and relationships shown are ALWAYS valid, no matter what the state of the object or what system it is a functional part of.

UML Notation (2):  Class Diagram

|

UML Notation (2):  Diagrams

|

UML Notation (2):  Object Diagram

The Object Diagram is a variant of the Class Diagram, using almost the same notation.  The Object Diagram shows only object instances, and it usually shows values for the attributes, as shown in the following slide.

Object Diagrams always have the object’s name underlined, and ALL instances of a class in a system are shown in an Object Diagram.

Object Diagrams are not as important as Class Diagrams, but they can help understand complex objects.  Object Diagrams are also used as part of Collaboration Diagrams.

UML Notation (2):  Object Diagrams

|

UML Notation (2):  State Diagram

The State Diagram is the dynamic aspect of the Class Diagram:  it shows ALL the possible states an object might have, and which events can cause the object to change state, as shown in the next slide.

Events can be any external stimuli, including a message from another object, such as a threshold being reached, condition fulfilled, or timer timed out, etc.  A change of state is called a transition.  A transition can also have an action connected to it that specifies what should be done when the state transition occurs.

State diagrams are only mandatory for major classes that have significant state behavior issues.

UML Notation (2):  State Diagram

|

UML Notation (2):  State Diagram

State (or Statechart) Diagram

A state 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, which is especially useful in modeling reactive systems.

Here we see two independent, concurrent state transitions:

|

UML Notation (2):  State Diagrams

State Transition Notation Summary:

|

UML Notation (2):  Diagrams

Interaction Diagrams:  Sequence  & Collaboration

Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams.  An interaction diagram shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them.  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.

UML Notation (2):  Sequence Diagram

|

UML Notation (2):  Sequence Diagram

The Sequence Diagram shows a dynamic collaboration between a number of objects, as shown in the next slide.  Typically, the Sequence Diagram shows the messages (events) sent from one object to another, the sequences of interactions and any precedences and dependencies in object interactions.

Time passes forward from top to bottom.  The events and messages are directed arcs, which may or may not have a return arc;  the return arc represents a synchronous dependency.

An arc which does not return indicates that the directed arcs which follow it do not depend on this return event.

UML Notation (2):  Sequence Diagram

|

UML Notation (2):  Collaboration Diagram

A Collaboration Diagram also shows a dynamic collaboration, just as the Sequence Diagram does.  In addition to showing object interaction (the sequence of messages), the Collaboration Diagram also shows the objects and their relationships (sometimes called the object ‘context’), as shown in the following slides.  The Sequence Diagram emphasizes time relationships and the Collaboration Diagram emphasizes context relationships.

The Collaboration Diagram features objects and messages on directed arrows, with labels added to show the order of the messaging.  Also shown can be conditions, iterations, return values, etc.  Concurrent objects can be shown.

UML Notation (2):  Collaboration Diagram

Collaboration Diagrams are often called ‘Object Message’ Diagrams.

|

UML Notation (2):  Collaboration Diagram

|

UML Notation (2):  Diagrams

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.

UML Notation (2):  Activity Diagram

The Activity Diagram is often used to show the activities performed in an operation, though it can also be used to describe other activity flows (i.e.:  a Use Case).  An Activity Diagram shows a sequential flow of activities, as shown in the next slide.

The Activity Diagram consists of action states, which contain a specification of an activity to be performed (an action).  An action state will leave the state when the activity is performed, unlike a state in a State Diagram which typically needs an event to occur before it changes state.  Decision points and conditions can also be shown in the Activity Diagram, as well as messages being sent or received.

UML Notation (2):  Activity Diagram

|

UML Notation (2):  Activity Diagram

|

UML Notation (2):  Component Diagram

The Component Diagram shows the physical structure of the code in terms of code module components.  A component can be source code, binary code (i.e., a font), or even executable code.

A component contains information about the logical class or classes it implements, thus creating a mapping from the Logical View to the component View, as shown in the next slide.

Component Diagrams can show overall module organization, dependencies, and interface details.  The Component Diagram is used in large scale projects to plot and map the source code organization from the logical object organization.

UML Notation (2):  Component Diagram

|

UML Notation (2):  Deployment Diagram

The Deployment Diagram, often called a ‘system riser’, shows the physical architecture of the hardware and software in the system, as shown in the next slide.  The actual target computers, nodes and network connections are diagrammed in the Deployment Diagram, including names and other property values.  Nodes can have details on the executables and objects resident there.  Deployment Diagrams can also show dependencies between components.

The Deployment View is the highest level physical architecture of the system.  Using a repository-based tool, it is possible to navigate from the Deployment View down to the most atomic Component View of any system.

UML Notation (2):  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.  They are related to component diagrams in that a node typically encloses one or more components.

|

UML Notation (2):  Deployment Diagram

Deployment diagrams can also be scaled up to show a macro view of a physical architecture:

|

UML Notation (2):  Diagrams

There are other diagrams in UML.  The basic Interaction Diagram introduced by Booch still exists in UML.  Also, the Package Diagram is gaining more usage, especially among Java programmers, since Java fully supports packages.

|

UML Notation (2):  Modeling with UML

As with OMT, the process of developing a system is iterative encompassing several ‘passes’ through different diagrams comprising many views.  These drawings can be perceived together as distinct ‘models’ (or phases) in the development process, similar to OMT:  Analysis, Design, Implementation and Deployment.

|

UML Notation (2):  Modeling with UML

UML is phase independent:  the same generic language and diagrams are used to model different things in different phases.  The system model is built through successive iterations, adding more detail, clarity and refinement.

A methodology needs to be used to get the desired result:  building the required system.  UML fully encompasses both the Booch and OMT Methodologies, with Use Cases added.  Beyond that, UML also needs a tool with an object repository to be properly utilized, especially for an enterprise developing software in teams (groups of programmers).  When properly used, the total life cycle from analysis through testing and deployment can be managed with UML.

|