Unified Modeling Language and the Microsoft Solutions Framework

This page uses modern project management strategies and tools to present the options for strategies and tools during various phases of a web system development project.

Take Microsoft's certification test on the MSF

Site Map  
About this site  

Phase 2. Design (Elaboration)

This plan is based on modern approaches to computer systems development: Microsoft's Solutions Framework and the Rational Unified Process, both developed for Object Oriented design. They are similar to the Muench model where requirements documents are successively refined as they are converted into design documents, which are also iteratively refined into more glandular (more detailed) specifications.

Each phase provides a different perspective for the various roles contributing to the project. A model is a description of a system in a context.

Standard Design Patterns may be used to reuse elements of a system's design.

The Solutions Design Process Model

The MSF descibes how during the design process, designs become more concrete and detailed.

 

 

Audience	Granularity of Requirements	Deliverable	Individual Documents
End-Users	Business Functional Requirements	Conceptual Design	Scenarios of Use Cases in Storyboards
Designers	System Requirements	Logical Design	Objects and Services User Interface, Logical Database Schema
Developers	Subsystem Requirements	Physical Design	Components User Interface, Physical Database Structure
Programmers	Unit Requirements	Final Design	Complete Application modules

UML - The Unified Modeling Language

Model Views	Focus	Diagrams
Use Case view	what functionality the system provides to its users.	Use-Case diagrams represents the scope and goals of actors triggering or using use cases within systems. They illustrate scenarios -- sequences of actions that illustrates behavior.
Structural (Static) view	what elements are in the system structure.	Class diagrams detail the properties and operations (methods) in the static (persistent) structural hierarchy of a system. They abstractly describe potential links among objects. Package Diagrams illustrate how model elements are grouped and divided, —as Java package and dependencies between packages are mapped to Java import statements. Object (Instance) diagrams depict the static structure of a system at a particular (instantaneous) point in time.
Behavioral (Dynamic) view	how elements interact over time to provide the functionality of the system.	Two types of Interaction diagrams show how objects interact with each other: Collaboration diagrams extend object diagrams by using numbered arrows to sequence the interaction of messages exchanged between objects. They are used to show how objects in a system interact over multiple use cases. Sequence diagrams illustrate when messages (requests) between objects (players/roles) are activated along a vertical timeline (from top to bottom). Additionally: Statechart diagrams use lines to depict events / actions causing transitions from initial to intermediate to final state Sample: Java threads Activity diagrams represent the behavior of an operation as a set of actions between an initial and final state. “Swimlanes” separates responsibilities among roles. They depict object and control flows between action states. Diamonds describe decision branching.
Implementation view	how the system is realized or implemented.	Component diagrams describe relationships among software components within the implementation environment. They indicate the choices made at implementation time.
Environmental view	the context (run-time configuration) of an implemented system in use.	Deployment diagrams show the configuration of run-time dependencies among artifacts (executables and script files) running on nodes (resources).

About the Unified Modeling Language

These Diagrams depict the relationships among model elements and artifacts.
• Artifacts are deliverables such as executable or script files created from effort.

• Model elements include classes, interfaces, components, use cases, and other objects.
  A class is a realization of an interface.
  An interface is a specification of a class.
  A class is a classifier of objects.
  A classifier is a description of an instance.
  An object is an instance of a class.
  Object instances <<originates from>> a Class. Note use of guillemet bracket characters here.
  Each instance of an object is an entity with a unique identity, behavior, and a state. It is represented by a box with two parts.

• Relationships among them include:
  • generalizations of concrete examples into an abstract concept. Represented by an arrow with a white arrowhead.
  • associations
  • compositions
  • dependencies
  • derivations

Packages

This collaboration diagram illustrates that UML model elements are grouped into packages that contain or reference model elements.



Two colons separate package names qualifying an element name

Package::Element

States

A solid round dot represents the initial (starting) state. A circle around a solid round represents a final (finishing) state.


Classes are represented by a box with three parts.

A classifier Role (or simply Role) defines an abstraction of an instance.
A Classifier Role specifies a single usage of its class.
Object instances <<conforms to>> a ClassifierRole.
ClassifierRoles are a <<view of>> a class.

The diagrams are visual representations of Object Constraint Language (OCL) text.
Classifier names are preceded with a colon.
ClassifierRoles names are preceded with a slash.

An Association Role specifies the required properties of a Link used in a Collaboration.

A collaboration has external initiators, active handlers, and passive managed entities.

As with any language, UML is defined by syntax and semantics. Syntax are rules by which language elements (e.g., words) are assembled into expressions (e.g., phrases and clauses). Semantics are rules by which syntactic expressions are assigned meanings.

UML.org unifies the syntax, graphic notations, and semantics from Booch, OMT, Objectory, and other object modeling languages.

UML 1.1 adopted Nov. '97 initally
UML 1.2 had editorial revisions without significant technical changes.
UML 1.3 doc# 06-08-99 adopted Nov. '99
UML 1.4 doc# 01-02-13 adopted Q2 2001
UML 2.0 adoption planned for end of 2002 breaks out into

• Infrastructure
• Superstructure
• OCL

The UML also includes:

• example profiles of Business Modeling and Software Development processes.
• CORBAfacility Interface Definition
• XML Metadata Interchange DTD

Zoomable, interrelated Championzone sample UML charts from Microsoft's Visio gallery. You can zoom in and out on these interrelated charts by clicking the “Fit in Window” and scrolling a wheel mouse.

Kendall Scott's UML Dictionary

The UML Forum

Ian Moraes' Introduction to the UML

$52 Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd ed.) by C. Larman (Upper Saddle River, NJ: Prentice Hall PTR (Pearson): 2002)

$45 Design Patterns Explained: A New Perspective on Object-Oriented Design by Alan Shalloway, James R. Trott (Reading, MA: Addison- Wesley (Pearson): 2001)

$45 UML and the Unified Process: Practical Object-Oriented Analysis and Design (Addison-Wesley, Dec, 2001) by Jim Arlow, Ila Neustadt

$25 Instant UML (Wrox Press Inc; 1st edition Dec 1997) by Pierre-Alain Muller

$35 UML Distilled : A Brief Guide to the Standard Object Modeling Language (2nd Edition) (Addison-Wesley: August 25, 1999) by Martin Fowler & Kendall Scott

$35 UML Toolkit (John Wiley & Sons; Book and CD-ROM edition October 14, 1997) by Hans-Erik Eriksson, Magnus Penker

The Unified Modeling Language User Guide by Booch, Rumbaugh, and Jacobson

UML Notation Guide, Version 1.1

$70 Object Models: Strategies, Patterns, and Applications (Prentice Hall: December 1996) by Peter Coad, David North, and Mark Mayfield

$32 Java Design: Building Better Apps and Applets (2nd Edition) (Prentice Hall: January 1999) by Peter Coad and Mark Mayfield

Mechanisms

UML is extended by Stereotypes, tagged values, constraints:
• Stereotypes specialize metamodel classes,
• tagged values extend the attributes of the metamodel classes,
• constraints extend the metamodel semantics.

  notes, dependencies, and type/instance and type/class dichotomies

Conceptual Design

Take the analogy of designing a physical building. It starts with the architect's sketches, providing a high-level view of the building for the client. They might contain a site plan, elevations, floor plans, cut away drawings, and other pictures or drawings. This view corresponds to the Conceptual Design for the project.

It all starts with an understanding of what the users really need to do and creating an easily communicated set of models that captures this understanding.

Logical Design

The architect's sketches are followed by architectural plans, showing the building as seen by the architect and contributing staff. This second phase in the architectural process combines the client's view with the architect's view and knowledge, providing detailed drawings in each of many categories for communication with the different contractors and other parties involved in the project.

This analogy corresponds to the MSF view of a Logical Design where we lay out the structure and communication among the individual elements of a system being developed.

Physical Design

Finally, contractors' plans are drawn up for the builder, adding detail to the architect's plans, making adjustments for the physical environment of the site and the technology and materials available to build the building. This view directs all the construction activities and may add greater detail such as shop plans for individual subcontractors.

This analogy corresponds to the Physical Design, where the real world constraints of technology are applied to the logical model including implementation and performance considerations. This is the point at which real resources, costs, and schedule can be estimated.

Final Design

The Final Design is a another name for the completed product released to the users.

The Application Model

Designed to improve development, maintenance, and support, this model provides a three-tiered, services-based approach to designing and developing software applications. The services utilized in this model are scalable, and can be used on a single desktop or on multiple servers worldwide. These models promote principles such as risk-driven scheduling, a fixed-release-date mind-set, versioned releases, visible milestones, and small, peer-based teams. MSF exposes critical risks, important planning assumptions, and key interdependencies required for successfully planning, building, deploying, and managing your company's mission-critical technology infrastructure or business solution.

Rational Process Workbench (RPW) creates “process” web sites from UML process models stored in Process Content Libraries manipulated by Rational Rose (also used to create Activity Diagrams from the models). RPW references the Rational Unified Process.

The Enterprise Architecture Model

Designed to shorten the enterprise architecture planning cycle, this model provides guidelines for building enterprise architecture through versioned releases.