Session 8: UML The Unified Modeling (or the Unstructured Muddling) language? A few observations, opinions, pros & cons COMP 320 / 420 Spring, 2018 Mr. Weisert Where did the UML come from? Object-oriented technology origin In the 1990s object-oriented programming (OOP) became acdcpted into mainstream software development methogology. Structured Programming had inspired Structured Analysis, so by analogy, it was thought that we ought to be able to apply the object paradigm to systems analysis, too. How did that work out? The object-oriented paradigm (We've seen this before but it's important.) Abstraction Encapsulation Inheritance Polymorphism Object-oriented programming That sounds good. Can we extend the concept to systems analysis (OOA)? Early (pre-uml) classic OOA work (textbooks) Coad & Yourdon: Object Oriented Analysis Booch: Object-Oriented Analysis & Design Rumbaugh: Object-Oriented Modeling & Design Jacobson: Others The Object Advantage Why isn't this course using one of those books? COMP 320 /420 Spring 2018 1-4 copyright 2008 Conrad Weisert
The "three amigos" Booch, Rumbaugh, & Jacobson were competitors each promoted his own version of OOA (differing mostly in graphical symbols). All 3 ended up working at Rational Software! Rational told them to cooperate on a unified approach. Now they all agree on UML Rational sells the dominant C.A.S.E. tools for O.O modeling, including Rational Rose IBM has bought Rational Software. Why is the UML of interest today? Wide acceptance among I.S. professionals for "analysis and design" What's "analysis & design"? Publicized, documented, and promoted by leading gurus, including: Grady Booch, James Rumbaugh, Ivar Jacobson. Martin Fowler, Ed Yourdon, etc. What's that? Blessed as a standard by OMG (for "modeling") Many recruiting ads now call for UML expertise/experience Why? Therefore.. Any software development organization (or individual professional) has to recognize the UML: a. by embracing it as the main components of its systems analysis methodology, or b. by rejecting it and adopting a practical alternative, or c. by selectively integrating the UML's best features into an established mainstream methodology, such as structured analysis (SA) We cannot ignore the UML What is UML? A mostly graphical language for system modeling. "a modeling language for specifying, visualizing, constructing, and documenting the artifacts of a system-intensive process." -- Alhir Not specifically intended for a functional specification (ESD, detailed requirements) But many people (including some "experts" who write books and teach courses) still think it was! Illustrates (again) confusion between analysis and design. Fails the user-understandability criterion for system specifications. COMP 320 /420 Spring 2018 5-8 copyright 2008 Conrad Weisert
Original UML objectives 1. To model systems, from concept to executable artifact, using object-oriented techniques. 2. To address the issues of scale inherent in complex, mission-critical systems. 3. To create a modeling language usable by both humans and machines. --UML User Guide, preface Who are the creators? Who are the audience? Intended scope "A healthy software organization produces all sorts of artifacts in addition to raw executable code. These artifacts include, but are not limited to: 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 User Guide, p. 16 What does that mean? UML has been immune from most criticism "It's not a methodology, only a language" Therefore UML promoters reject or ignore criticisms on methodology grounds. "It's not for system specification, but for system modeling." Therefore UML promoters reject criticisms on understandability grounds. "You must have requirements first!" --Oops! Is the UML a methodology component? Of course. When UML proponents claim that it's not, they mean only that it's not a process or a system-development life-cycle. Actually it is closely tied to its own standard life cycle! COMP 320 /420 Spring 2018 9-12 copyright 2008 Conrad Weisert
The critical point: We know that The end of phase 3 (in our model life cycle), External System Design, is the most important point in a project. It is the last point: at which changes can be made without huge cost, where the sponsoring end users can be expected to understand the deliverables in full detail, that is (or should be) independent of: choice of operating platform(s) make-or-buy choice for major software components development tools and methodologies etc. Weisert's Rule #2 on project failure Inadequate external design is one of the two most common reasons why projects fail. That is, the content is one or more of these: incomplete erroneous, inconsistent incomprehensible to the intended audiences mixed up with internal design especially this--why? Five views of a system (according to UML) Design view Process view use-case view Implementation view Deployment view - from UML User's Guide, p. 31 What ties them all together? Who makes sure they're consistent? How? Modeling different views "When you model a system from different views, you are in effect constructing your system simultaneously from multiple dimensions... If you do a poor job of choosing these views or if you focus on one view at the expense of all others, you run the risk of hiding issues and deferring problems that will eventually destroy any chance of success." --UML U.G., p. 98 Do we believe that? How do we decide? COMP 320 /420 Spring 2018 13-16 copyright 2008 Conrad Weisert
Question Is is desirable (acceptable) for the systems analyst to prepare two separate versions of the ESD deliverables? one in business-oriented language for the sponsoring end users the other in technical language for the developers What about five different versions ("views") Some UML diagrams (as of UML 2.0) Structural diagrams a. Class diagrams b. Component diagrams c. Composite structure diagrams d. Deployment diagrams e. Package diagrams f. Object diagrams Behavioral diagrams g. Activity diagrams h. Communication diagrams i. Interaction diagrams Sequence diagrams Collaboration diagrams j. State-transition diagrams k. Use-case diagrams Wow! What does this imply? Reminder: There is no such discipline as "analysis & design" Systems analysis and System Design are done at different times during a project demand very different skills and techniques Analysis describes the external view of a proposed new software system. What Design describes the internal view of a system How The UML's Life Cycle Since UML claims to be process-independent, UML gurus assure us that it's OK to follow any SDLC we like, as long as that life cycle is: use-case driven architecture centric iterative and incremental How many SDLCs can satisfy those criteria? By the way, here's one ("Objectory" -Jacobson) Inception phase Elaboration phase Construction phase Transition phase Rational has renamed it UP COMP 320 /420 Spring 2018 17-20 copyright 2008 Conrad Weisert
Initial Objectory (UP) phases Inception phase: Like traditional "project initiation" + "business requirements" Defines: project scope initial justification Elaboration phase Like traditional "functional specification" or "external system design" (ESD) "During the elaboration phase you need to get a good handle on the requirements and their relative priorities." -Fowler, p. 17 Objectory phases (continued) Elaboration phase (another view) "... usually uses one iteration cycle and involves the following activities: Elaborate the specification of the effort from the previous phase. Baseline and completely delimit scope, objectives, and requirements. Baseline the business case by solidifying the vision, solifying success criteria, and mitigating the highest risks. Baseline the plan with a schedule. Distribute the requirements among multiple iteration cycles within the construction phase. - (more) Objectory phases (continued) Elaboration phase (continued) "Focus on understanding or forming a notion of the problem to determine the requirements that the problem imposes on its solution... establishing and verifying the foundation for the overall solution (architectural design) and distributing the requirements among the iteration cycles of the construction development phase) - Alhir, p. 23 Clearing it all up "During the elaboration phase, as we have already noted, we build the architecture. We identify the use cases that have a significant impact on the architecture. We realize these use cases as collaborations. It is in this way that we identify most of the subsystems and interfaces--at least the ones that are architecturally interesting. Once most of the subsystems and interfaces are identified, we flesh them out, that is, write the code that implements them. Some of this work is done before we release the architectural baseline and it continues throughout all of the workflows." - Ivar Jacobson COMP 320 /420 Spring 2018 21-24 copyright 2008 Conrad Weisert
Objectory phases (concluded) Summary: A little of this and a little of that in each of the four phases! Emphasis on system architecture from the start poses serious problems: obscures the business problem or opportunity blurs distinction between analysis and design rules out consideration of packaged software product Descriptions by gurus permeated by vagueness and lack of rigor ("get a handle on", "form a notion of", etc.) Class diagrams "Static design view" of a system A point of similarity between UML and other versions of OOA (e.g. Coad & Yourdon) For each type of data item specifies: its attributes (components / "has-a" hierarchy) its behavior (methods / interface) Relationships among classes: Inheritance ("is-a hierarchy) Entity-relationships Logical database design Some other UML diagrams that may be useful in an ESD Interaction and collaboration diagrams State-transition diagrams--what happens in response to a triggering event? Important UML issues Assumes custom architecture and in-house software development; little provision for evaluating, selecting, and integrating application program products. There's no clear starting point: for creating for reading No definite way to know when the model is complete. Relies on the system modeler to keep multiple independent diagrams and other documents consistent with one another. COMP 320 /420 Spring 2018 25-28 copyright 2008 Conrad Weisert
The bottom line: 5 serious UML shortcomings The user audience can't understand the specifications (ESD) in UML form There's no logical starting point or ending point Multiple views invite (and conceal) inconsistency. Weak distinction between analysis and design. Rules out buying packaged application software. The requirements crisis Large projects that try to follow UML / UP often experience a serious deficiency in gathering, organizing, understanding, and approving the users' requirements; Abandonment of structure, in particular: Where do we begin? How do we know when we're done? Overwhelming detail Compare with DeMarco's "Victorian novel" approach to system specification. How did we come to abandon requirements structure? Chronology from ca. 1991: Object-oriented analysis is good. How do we know? Analogy: Structured programming (1972) was good It led to structured analysis (1978), also good Object-oriented programming (1990) was good Object-oriented analysis must be good, too! How did we come to abandon requirements structure? Chronology from ca. 1991: Object-oriented analysis is good. UML (Booch-rumbaugh) is standard for OOA. Sponsoring users and other non-technical audience can't understand UML requirements specifications. Jacobson adds use-cases to UML Users can't understand use-cases either--oops! Unstructured "requirements lists" substituted! Back to the 1960s! What happened to our life cycle? COMP 320 /420 Spring 2018 29-32 copyright 2008 Conrad Weisert
An extreme reaction Chronology from ca. 1991: Object-oriented analysis is good. UML (Booch-rumbaugh) is standard for OOA. Sponsoring users and other non-technical audience can't understand UML requirements specifications. Jacobson adds use-cases to UML Users can't understand use-cases either--oops! Unstructured "requirements lists" substituted! Reject / ignore anything associated with discredited "traditional" or "structured" systems analysis (SA) A suggested 2018 way of documenting the results of systems analysis Continue using structured systems analysis (e.g. per DeMarco, Robertsons, etc.) as the framework but use O.O. class diagrams for data dictionary encapsulated behavior where appropriate, inheritance hierarchy Form your own judgment: based on your user community anything that works Sources Not a recommended bibliography, but just sources of quotes for this presentation from various UML advocates: Ivar Jacobson: The Object Advantage, AW, 1994, 330 pages Martin Fowler & Kendall Scott: UML Distilled, AW, 1997, 180 pages Grady Booch et al: The Unified Modeling Language User Guide, AW, 1999, 475 pages Si Alhir: UML in a Nutshell, O'Reilly, 1998, 275 pages Too heavy to bring all of them to a classroom in a different building from instructor's office! COMP 320 /420 Spring 2018 33-36 copyright 2008 Conrad Weisert