MUCIT THE UNIFIED MODELLING LANGUAGE UML MUCIT MODELLING

MUCIT THE UNIFIED MODELLING LANGUAGE UML

MUCIT MODELLING

Overview MUCIT • • Why we model? Modeling complex systems conclusion

Why we model MUCIT • Why do we need to model things? • How does modeling help? • Is modeling always absolutely necessary

Why we model MUCIT • Software models are very similar to. . . Mechanical Drawings Electrical Schematics Construction Blueprints

Why we model MUCIT • Compare building a dog house with – A family house – An office block

The point MUCIT • You would not start to build an office block with the skill and resources of the dog house builder • Unfortunately many people approach building “office block” systems as if they were building a “dog house” system • Almost impossible to assess size or complexity of systems

Modeling MUCIT • Projects fail for many reasons – Complexity – Lack of understanding – Communication problems • Projects succeed for many reasons • One common thread is modeling

Components needed for a successful project MUCIT • You can learn a notation, but if you don’t know how to use it (process), you’ll probably fail. Notation Tool Process Triangle for Success

Components needed for a successful project cont. . MUCIT Notation • You may have a great process, but if you cannot communicate the process (notation), you Tool will probably fail. Process Triangle for Success

Components needed for a successful project cont… MUCIT • Lastly, if you cannot document the artefacts of your work (tool), you will probably fail. Notation Tool Process Triangle for Success

Why do we model? MUCIT • To communicate efficiently – Between people with different backgrounds – A common language • To visualise the final product – To help potential end users • To analyse the final product – Safety – reliability

What is a model? MUCIT • Simply put: A model is a simplification of reality. • We build a model as: A simplification of reality • In order to: Better understand the system under development • Because: We cannot comprehend complex systems

What is Visual Modeling MUCIT • It is a way of thinking about problems using models organized around real-world ideas. Useful for understanding problems, communicating with every one involved with project, modeling enterprises, preparing documentation, designing programs and databases.

Visual Modeling MUCIT • Helps organize, visualize, and understand complexity. • Is the mapping of real processes of a system to a graphical representation. • Is an abstraction that portrays the essentials of a system, making the problem easier to understand. • Is a proven and accepted engineering technique. • Has a common vocabulary, the UML.

Aims of modelling MUCIT • • To visualise a system To specify a system To provide a template for creation To document decision made

The four principles of modeling MUCIT • • The choice of model The abstraction of the model Connection to reality Independent views of the same system

The choice of model MUCIT • Has a big influence on how a problem is approached. • Use the right models for the right job • Consider: – Electronic circuits – Radio systems – Maths • Considering an incorrect model can be costly

The abstraction of the model MUCIT • When modeling anything it is crucial to get the level of abstraction correct – In terms of numbers (many or few) – Looking at the overall system – It could be focusing on a tiny part of the system • Important to look at different levels of abstraction

Connection to reality MUCIT • Remember, all models simplify reality – This creates an inherent danger – Simplify implies missing out information • The model must reflect the real world – E. g mathematical models – E. g architectural drawings • The connection must be clear.

Independent views MUCIT • No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models. – Many views are required to have a full model • Different people need different views – Don’t bother people with information they don’t need • Different views must be viewed together • Different models must be consistent with each other.

Modelling complex systems MUCIT • There are many types of modelling: – Mathematical – Visual etc. . • All are valid where appropriate • We will concentrate on visual modelling

The UML MUCIT • The modeling technique we shall use is the unified modeling language • Visual modeling language – Has rules – Syntax – Semantics • Tools are available

What is the UML? MUCIT Unified Modeling Language An industry standard design notation for: • • Expressing software requirements Expressing software architecture Expressing software dynamics and behavior Documenting software deployment The de-facto industry standard today Current OMG Specification 2. 0

What is UML? MUCIT • 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 nonsoftware systems. • The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. • It represents the unification of the Booch, OMT and Objectory notations. • The UML plays a very important role in the developing of object oriented software and the software development process. • The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.

Goals of UML MUCIT 1. 2. 3. 4. 5. 6. 7. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. Provide extensibility and specialization mechanisms to extend the core concepts. Be independent of particular programming languages and development processes. Provide a formal basis for understanding the modeling language. Encourage the growth of the OO tools market. Support higher-level development concepts such as collaborations, frameworks, patterns and components. Integrate best practices.

Why Use UML? MUCIT • As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include – component technology, – visual programming, – patterns and – frameworks. • Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. • Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs.

Origins of UML MUCIT • Identifiable object-oriented modeling languages began to appear between mid-1970 and the late 1980 s as various methodologists experimented with different approaches to object-oriented analysis and design. • The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989 -1994. • Many users of OO methods had trouble finding complete satisfaction in any one modeling language, fueling the "method wars. " • By the mid-1990 s, new iterations of these methods began to appear and these methods began to incorporate each other’s techniques, and a few clearly prominent methods emerged.

Origins of UML MUCIT • The fall of the method wars as far as notation is concerned comes with the adoption of the UML • The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods. • In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (Object. Oriented Software Engineering) method

Motivation for creation of UML MUCIT • As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for three reasons. • First, these methods were already evolving towards each other independently. It made sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. • Second, by unifying the semantics and notation, they could bring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features. • Third, they expected that their collaboration would yield improvements in all three earlier methods, helping them to capture lessons learned and to address problems that none of their methods previously handled well.

UML Inputs Booch MUCIT Rumbaugh (OMT) Mayer Odell classification Pre and post conditions UML Harel Shlaer-Mellor State charts Object life cycles Gamma et al Frameworks, Patterns, notes Jacobson Wirfs-Brook Embly Fusion Responsibilities Singleton classes Operation descriptions Message numbering

The UML and Software Process MUCIT • The UML is a standard notation only • It does not specify process at all • UML is most effective when combined with an effective software process

Why use UML for A & D? MUCIT q Clarity-Graphical depictions of ideas are easier to immediately understand q Audience-This ‘clarity’ allows a wider audience to understand participate q Discipline- Modeling, as a rigorous technique, imposes discipline on the specifications of business problems and a common language to understand resolve them.

Why use UML for A & D? MUCIT Clarity-Graphical depictions of ideas are easier to immediately understand

Why UML at Implementation? MUCIT • Communicating between team members • Waiting on finished work from others • Resolving unforeseen problems • Updating management at code review • Understanding impact of changes • Taking time to document the code • Completing error prone steps

MUCIT Benefits of UML at Implementation? • Task Automation – Many simple, repetitive tasks can be handled automatically • Visual Guidance – UML models provide a guide to development and a perspective that encourages efficient design • Communication – Up to date, design records provide an efficient communication vehicle

Visual Guidance MUCIT Navigation • Use ‘picture’ of code to point and click your way through design. • Navigate between objects on different diagrams and within different areas of code visually

Visual Guidance MUCIT Refactoring • UML provides the opportunity to visually inspect, improve, debug, and enable reuse of code“Refactoring is the process of Banner. Ad - Start. Time : int - End. Time : int + add. To. Sch ( Banner. Ad ad ) : boolean + verify ( ) : void + set_Start. Time ( int value ) : void + get_Start. Time ( ) : int + set_End. Time ( int value ) : void + get_End. Time ( ) : int + set_Image. File. Name ( value ) : void changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. ” Refactoring: Improving the Design of Existing Code Fowler, Martin. 1999. Addison Wesley

Communication MUCIT Project Status • Reports provide quick visual inspection of project status • No special preparation necessary for code review • Not necessary for management to read thru code or accept a verbal status report

Communication MUCIT Learning Curve • Big picture blueprint of architecture and interfaces • New developers get understanding of overall architecture and become more productive more quickly.

SOFTWARE CODE VS. MODEL MUCIT OR 7 source files 940 lines of code One diagram

Types of models MUCIT • There are two types of models (in the UML) – Static (tells what). – Behavioral (tells us how) • Each type of model – Must exist – May be modelled by different types of diagrams • Absolutely fundamental to understand the UML

Kinds of Diagrams MUCIT UML 2. 0 defines 13 basic diagram types, divided into two general sets: • Structural – Structure diagrams define the static architecture of a model. – They are used to model the 'things' that make up a model - the classes, objects, interfaces and physical components. – In addition they are used to model the relationships and dependencies between elements. – Class – Object – Component & – Deployment – Composite – Package diagrams

Kinds of Diagrams MUCIT • Behavioral • Behavior diagrams capture the varieties of interaction and instantaneous state within a model as it 'executes' over time. – – – – Use case Sequence Activity Communication Timing diagram Interaction overview Collaboration Statechart

Kinds of Diagrams Scope for this course MUCIT • We shall consider: – – – Use case Activity Class Diagram Object Diagram Sequence Collaboration

Conclusion MUCIT • • There’s need for modeling There are requirements for modeling The modeling language chosen is UML The UML has two types of model or views – Static (what) – Behavioral (how) • Each model may be realized using one or more UML diagrams

Types of UML Diagrams MUCIT Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. UML diagrams commonly created in visual modeling tools include: • Use Case Diagram displays the relationship among actors and use cases. • Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing.

Types of UML Diagrams • Class Diagram models class structure and contents using design elements such as classes, MUCIT packages and objects. It also displays relationships such as containment, inheritance, associations and others. 1 • Interaction Diagrams – Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects). 1 – Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages. 1