DesignGuidelines.pdf - Copyright 2002 Department of...

Info icon This preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
1 Copyright 2002 Department of Computer Science, Rochester Institute of Technology All Rights Reserved Introduction A software design is useless if it cannot be clearly, concisely, and correctly described to the programmers writing the code. In the construction industry, architects use blueprints to describe their design to the contractors responsible for constructing the building. Software architects need a similar form of “software blueprints”, that is, a standard way of clearly describing the system to be built. Here we introduce the Unified Modeling Language (UML), a graphical modeling language used to visually express the design of a software system. UML provides a way for a software architect to represent a design in a standard format so that a team of programmers can correctly implement the system. Prior to the development of UML there were many different and incompatible techniques that software architects used to express their designs. Since there was no one universally accepted method, it was difficult for software architects to share their designs with each other, and more importantly with the programming teams responsible for implementing the software. In 1994 Grady Booch, James Rumbaugh and Ivar Jacobson (this group of Computer Scientists is often referred to as the “three amigos”) started work on UML. One of the goals of UML was to provide a unified way of modeling any large system, not just software, using object-oriented design techniques. In order for UML to be widely used it was important that the language be available to everyone. Therefore, the resulting language is a nonproprietary industrial standard and open to all. There are several aspects of a system that need to be described in a design. For example, the functional aspects of a system describe the static structure and the dynamic interactions between components in the system, whereas non-functional aspects include items such as timing requirements, reliability, or deployment strategies. In order to provide a way to describe all of the relevant aspects of a software system, UML provides five different views that document the various aspects of a system. A view is an abstraction consisting of a number of diagrams that highlight a particular aspect of the system. The five views provided by UML are summarized in Table 1 below:
Image of page 1

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon