Free E-book : Model-Driven Development with Executable UML 

Part I: Introduction
Chapter 1: Information Systems Modeling . .
Chapter 2: Traditional Approaches to IS Development .
Chapter 3: The Object Paradigm . . . . . . .

Part II: Overview of OOIS UML
Chapter 4: Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 5: Basic Language Concepts . . . . . . . .
Chapter 6: Interaction and Querying . . . . . . . . . . . . .

Part III: Concepts
Chapter 7: General Concepts . . . . . . . . . . . . . .
Chapter 8: Classes and Data Types . . . . . . . . . . . . . .
Chapter 9: Attributes . . . . . . . . . . . . . . . . . . . .
Chapter 10: Associations . . . . . . . . . . . . . . . .
Chapter 11: Constraints. . . . . . . . . . . . . . . . . . . . . . . .
Chapter 12: Querying . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 13: Operations and Methods . . . . . . . . . . . . . . . . . . . .
Chapter 14: StateMachines. . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 15: Collaborations and Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Chapter 16: Commands, Presentation, and Architecture . . . . . . . . . . . . . . . . . . 547

Part IV: Method
Chapter 17: About theMethod . . . . . . . . . . . . . . . . . . . . .
Chapter 18: Conceptual Modeling . . . . . . . . . . . . . . . . . .
Chapter 19: Modeling Functional Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . 631

Part V: Supplemental
Chapter 20: Characteristics of Information Systems. . . . . . . . . . . . .
Chapter 21: Process and Principles of Software Development . . . . . . . . . . . . . 685
Chapter 22: The Relational Paradigm . . . . . . . . . . . . . .
Chapter 23: Structured Analysis . . . . . . . . . . . . . . . . . . . . . . .
Chapter 24: Introduction to the Object Paradigm .

*********

Information Systems Modeling
To provide a foundation for the discussions throughout this book, this chapter begins by defining what is actually meant by the term information system. The focus is on model-driven engineering of the software component of information systems. This chapter also introduces and describes the very notion of modeling. The chapter concludes with a brief discussion about software engineering processes, an important aspect of building successful information systems.

Definition of Information Systems
Information systems have played a key role in the history of computers and their use in everyday human activities. It is hard to imagine even a small company, institution, or organization that does not have a need for storing and using information of a different kind.

We are all witnesses of the tremendous improvement of computer and communication technology, which support ever-increasing demands of human community for interchanging and utilizing information. It is not necessary to discuss the role and importance of information systems such as healthcare systems, enterprise systems, banking and financial systems, educational information systems, customer-support systems, governmental systems, and many other kinds of information systems

Trying to catch up with the importance and ever-emerging demand for improved functionality and performance of such systems, the hardware and software technology for their implementation seem to constantly stay behind. It has always been a question of how to improve the technology (especially that for software development) to meet the users’ needs. Because this question defines the scope of this book, before trying to answer it, it is necessary to set up the context and define what information systems really are.

First and foremost, information systems are systems. A system is a set of elements organized to cooperate in order to accomplish a specific purpose. Elements of a systemcollaborate synergistically, in a manner that provides a behavior and quality bigger than the sum of its parts. It is likely that a....

  Free E-book : Model-Driven Development with Executable UML 

Ebook  Learning UML 2.0 / PDF

What is UML?
Unified Modeling Language…
…is thestandard language for specifying, visualizing, constructing, and documenting software systems…
…as well as for business modeling and other non-software systems.


Why use UML?
Software project failure rate:
1994 (first CHAOS report): 84%
2001 (“extreme CHAOS”): 72%
2003 (most recent CHAOS): 69%

One solution: UML.

Modeling is an essential part in systems design.
UML design supports requirements for scalability, robustness, security, extensibility, and other characteristics, beforeimplementation in code renders changes difficult and expensiveto make.

It’s a (semi-)formal language.

It’s concise.
It’s comprehensive.
It’s scalable.
It’s built on lessons learned.
It’s the standard.

A Brief History of UML
1967: foundations of OOP –Nygaard, Goldberd, Stroustrup, Harel, Meyer…
1996: Rumbaugh, Booch, Jacobson –The Three Amigos
1997: UML 1.1, an OMG standard
1997-2003: UML 1.1, 1.3, 1.4, 1.5
2004: UML 2.0A Brief History of UML


Structure Diagrams
Class Diagram: classes, types, interfaces, and the relationships between them. (UML 1.x)
Component Diagram: important components within the system and the interfaces they use to interact with each other. (UML 1.x, revamped in 2.0)
Composite Structure Diagram: the internals of a class or component, and can describe class relationships within a given context. (UML 2.0)
Deployment Diagram: how the system is finally deployed in a given real-world situation. (UML 1.x)
Object Diagram: object instances of the classes defined in class diagrams in configurations that are important to the system. (informally UML 1.x)
Package Diagram: the hierarchical organization of groups of classes and components. (UML 2.0)
Class Diagram: classes, types, interfaces, and the relationships between them.

Ebook  Learning UML 2.0 / PDF

Tutorial video  : UML Use-Case diagrams 

Use Case Diagrams

nUse Case diagrams show the various activities the users can perform on the system.

nSystem is something that performs a function.

nThey model the dynamic aspects of the system.

nProvides a user’s perspective of the system.

nA set of ACTORS : roles users can play in interacting with the system.

nAn actor is used to represent something that users our system.

nA set of USE CASES: each describes a possible kind of interaction between an actor and the system.

nUses cases are actions that a user takes on a system

nA number of RELATIONSHIPS between these entities (Actors and Use Cases).

nRelationships are simply illustrated with a line connecting actors to use cases.

Use Case Diagrams - Actors

nAn actor  is  a user of the system playing a particular role.

nActor is shown with a stick figure.

Use Case Diagrams – Use Cases

nUse case is a particular activity a user can do on the system.

nIs represented by an ellipse.

nFollowing are two use cases for a library system.

Tutorial video  : UML Use-Case diagrams 

Teach yourself concept and UML class with video 

Object-Oriented Technology Concepts

•Object

•Class

•Attributes

•Operations

•Relationships

•Messages

•Persistence

•State

Defining Objects

An OBJECT is an abstraction of a person, place, thing, or concept within the problem domain that the information system must be aware of.

Defining Class

A CLASS is a template (specification, blueprint) for a collection of objects that share a common set of attributes and operations.

Objects

• Objects have three responsibilities:

*What they know about themselves – (e.g., Attributes)

*  What they do – (e.g., Operations)

*What they know about other objects – (e.g., Relationships)

Teach yourself concept and UML class with video 

learn UML with video tutorial : introduction 

INTRODUCTION



UML is a result of the evolution of object-oriented modeling languages. It was developed by Rational Software Company by unifying some of the leading object-oriented modeling methods,

• Booch by Grady Booch,
• OMT (Object Modeling Technique), by Jim Raumbaugh and
• OOSE (Object-Oriented Software Engineering), by Ivar Jacobson.

The authors of these languages are sometimes called the three amigos of software engineering. They were participating in the around twenty people strong group which was formed in ’94 and submitted UML 1.0 to the Object Management Group (OMG) in ’97. The current version of UML is 1.4 (published in Sep 2001) and there is ongoing work within OMG on a new major version 2.0, planned to be released during late 2003 or early 2004.

UML is used for modeling software systems; such modeling includes analysis and design. By an analysis the system is first described by a set of requirements, and then by identification of system parts on a high level. The design phase is tightly connected to the analysis phase. It starts from the identified system parts and continues with detailed specification of these parts and their interaction. For the early phases of software projects UML provide support for identifying and specifying requirements as use cases. Class diagrams or component diagrams can be used for identification of system parts on a high level. During the design phase class diagrams, interaction diagrams, component diagrams and state chart diagrams can be used for comprehensive descriptions of the different parts in the system.

We will start by giving the basic building blocks of UML, and then introduce the most essential UML diagrams one by one, each with a small example. Finally an example with a couple of diagrams is given to illustrate how the diagrams can be combined to describe the design of a small software system.

learn UML with video tutorial : introduction 

Free tutorials on UML for beginners / PDF

Using Rational Rose in conjunction with the notes on the web server relating to UML, attempt to model the combined light, switch and bulb classes in the following way:-

Ø  In the Use-case view of rational rose, create a new actor called ‘home owner’ and drag this actor from the ‘use-case view’ to the ‘logical view’. (see below)

For the remainder of the points below, assume that they refer to the logical view.

Ø  Create a new ‘use-case diagram’ called ‘Main’, double click on it to open it up and drag the home owner actor onto it.

Ø  Now introduce two ‘use cases’ called ‘Lamp on’ and ‘Lamp off’ and place them on the ‘use-case diagram’ and connect the ‘home owner’ (actor) to the two use-cases via a ‘uni-directional association’ to show that this actor interacts with the them. You should now see something like this which attempt to capture the users two main interactions with the system.

Ø  Double click on each of the two use-cases in turn to open their specification and type in a description of what they do i.e. turn the switch and bulb on (or off) accordingly. See below for a simple example. This description captures the requirements for that particular use-case. Obviously this is a very simple example and hence the description is correspondingly straight forward.

Now we are going to use a class diagram to represent each of the classes that will be needed to model our system. In this class diagram we are attempting to capture the essential relationships that exists between instances or objects of those classes.

Ø  By default rational rose creates a class diagram for us in the logical view called ‘Main’. Double click on this to open it.

Ø  Create new classes called ‘lamp’, ‘bulb’ and ‘switch’ in the logical view browser and drag them onto the ‘Main’ class diagram. (See below)

Using your notes on UML from the web-based server, learn how to add attributes and member functions to your class and also how to set the multiplicity and containment of classes. See if you can replicate the following diagram

This shows that all classes have a single data item or attribute called ‘state’ which is private and which is represented by an ‘int’. Likewise all classes have two member functions called On() and Off() which are public (we’ll ignore constructors and destructors and the other functions you wrote for your classes in C++ until later)

The above diagram also shows that there is a relationship between the Lamp and the Bulb, and between the Lamp and the Switch indicated by the line (known as an association) connecting them. The ‘1’ highlighted at each end is known as the multiplicity and indicates how many instances of a Lamp exists for each instance of a Bulb and Switch. In this case it shows that each Lamp has exactly one bulb and one switch. That is for each instance of a lamp, there will exist one switch and one bulb that belong to it and that each bulb and switch belongs to exactly one Lamp (they cannot be shared between two lamps for example). The arrow at the end of the association indicates that messages may be sent from the lamp to the bulb (but not the other way around). If bidirectional message passing is required (from lamp to bulb and from bulb to lamp) then an association with NO arrows on it is used. This is in fact the default when an association is first created.

Note that there is a filled diamond on the Lamp end of the relationship. This indicates containment by value, i.e. that the Lamp ‘owns’ the switch and bulb in other words the bulb and switch are ‘part-of’ the lamp.

This containment implies that when a lamp is created, a bulb and a switch must also be created and likewise when the lamp is destroyed the bulb and switch and also destroyed. In other words their lives are interconnected and thus a bulb cannot exist without the lamp and vice-versa. We implemented this containment in C++ using aggregation by placing an instance of a bulb and a switch inside a  lamp e.g.

class Lamp      {

private:   Bulb b1 ;                   // C++ containment of a bulb by value

              Switch s1 ;                 // C++ containment of a switch by value

            …

};

If we had drawn the diagram like this with open diamonds representing containment by reference on the end of the relationship, then it would imply that the lives of the Lamp, Bulb and Switch are not interconnected and could lead separate lives and existences, i.e. we could create an instance of a bulb and a switch quite separately without there having to be a Lamp and vice-versa. The lamp could then be given its bulb and switch separately at some point in the future, in fact that could even be replaced or swapped out

Note that when we changed the containment from one of ‘value’ (filled diamond) to one of ‘reference’ (open diamond) we had to change the multiplicity from ‘1’ to ‘zero-or-one’ to indicate that at any point in time a lamp object could actually exist with either no switch/bulb or one switch/bulb since their lives are now independent. In C++ containment by reference is implemented using pointers as shown below.

class Lamp      {

private:   Bulb   *b1 ;                 // C++ containment by reference using a pointer

              Switch *s1 ;                // C++ containment by reference using a pointer

            …

};

Obviously introducing an instance of the lamp will not automatically introduce an instance of the bulb or switch (only a pointer to them). We have two solutions to addressing this. Firstly we could write our lamp constructor to automatically create a bulb and switch object using operator ‘new’ or alternatively we could include a ‘swapbulb()’ or ‘attachbulb()’ function to allow us to swap or attach an existing bulb (and switch) at some point after the creation of the lamp.

The choice of containment type is up to us but it would appear that containment by reference (i.e. using pointers) whilst adding somewhat to the complexity of the code, gives us a degree of flexibility not afforded when using containment by value, that is, it gives us the ability to attach and detach the bulb and switch to/from the lamp and is more realistic in the sense that real bulbs ‘blow’ and will need replacing.

Class Associations: Containment vs. Association

Yet another alternative representation of the above classes is shown below, where containment (either by reference or value) is NOT represented. In essence the classes are linked by associations (i.e. no diamonds on the end). This means that the lamp does not own the bulb or switch and thus they can have quite separate lives but it does rely on their existence and co-operation in order to work. It’s a philosophical debate as too which approach is better, but the question you should ask is which one do you feel comfortable with?.

If in your opinion you see one object as containing or being composed of another then show some form of containment on the class diagram. If you view the classes as just co-operating then just show an association. The implementation of an association is the same as it would be for containment by reference, i.e. the lamp would contain pointers to the bulb and switch....

Free tutorials on UML for beginners / PDF

Fundamentals of UML and Class Diagrams and Sequence and Activity Diagrams 

Introduction to UML

The Unified Modeling Language (UML) is a mainly graphical notation for specifying, visualising and constructing the descriptive diagrams and documentation of software system. It is the industry standard for object-oriented modelling, created and maintained by the Object Management Group.

UML1 was adopted in 1997, and combined the best approaches from various diverse modelling languages that had been developed since the introduction of object-oriented programming. UML2, adopted in 2005, provides more diagrams, and significant improvements in usability and consistency.

UML can be used at various different levels.

• The most common and recommended approach is to use it to sketch complex problems in a fairly informal way, to aid understanding. You should be selective, and only draw a diagram if it shows details more clearly than just a text description.
• UML can also be used to create a complete blueprint of the system. This is usually too time-consuming, especially if design changes before the project is complete.
• Finally it could be used as a programming language, where diagrams can be transformed to executable code. This use is not widespread.

UML can be used at the design stage, to determine requirements, classes and the interaction between them. It can also be used for documentation, to record the final requirements, classes and interactions.

There are many good books on UML, such as ML Distilled Third Edition by Martin Fowler : Addison Wesley  ISBN 0-321-19368-7. This book is chatty and compact, drawing on the author’s experience.

There are many tools which can be used to create UML diagrams. The disadvantage of these is that they often offer many facilities which aren’t needed on this module, and so are fairly complex to learn, and may automatically suggest notation which is incorrect for your diagram. The advantages are that the diagrams are probably easy to alter, may generate skeleton code, and you can mention them on your CV.  In the lab, we have ArgoUML and Dia. Asking students in the past what they prefer has never come up with a firm favourite. I mostly draw my diagrams using the Draw option in powerpoint, simply because I know how to do that. Even neat hand-drawn diagrams are acceptable (but scan a copy for yourself before handing anything in).

Class Diagrams

The class diagram shows the state and behaviour of objects of a particular class, by splitting the rectangle into three sections.

An object has a public interface defining the operations it will support.

An object can have private internal operations, for its own use only

An object has private internal data, attributes, which only its own operations can access.

The access modifier specifies whether other classes are permitted to use the attribute or operation. Modifier values are:

+     public           can be accessed by any class

-      private          can be accessed only by this class

#     protected      can be accessed by this class and its subclasses

A line joining the classes represents an association between objects of that class. We optionally attach a label to the association, with a black triangle to indicate direction (e.g. Owner has Dogs).

We can also add multiplicities to show the degree of association - very much like entity-relationship diagrams. Note how they are read

·         An owner has 0 or more dogs.

·         A dog has only one owner.

 

When drawing associations, the attributes and operations are sometimes omitted. This is a good idea when there are a lot of classes – use classnames only and show links between the classes, and show the attributes and operations in a separate diagram.

Open arrow heads on the associations show navigability. This indicates which object needs to know about which other object to make an association work. We try to keep navigability one way to reduce coupling – the number of links between classes.

You may also see diamonds, open or filled, on the association lines. These represent aggregation and composition, and should be used with care. I wasn’t going to cover these in this course, but since you will find them in UML tools, I had better mention them.

Association represents the ability of one instance to send a message to another instance. This is typically implemented with a pointer or reference instance variable, although it might also be implemented as a method argument, or the creation of a local variable.

Aggregation is an association which specifies a whole/part relationship, and is shown with an open diamond. E.g. A Team consists of Employees and subTeams.

Composition is a stronger aggregation, in which the part does not exist without the whole. It is shown with a filled diamond.

So you can see that you should not freely add filled in diamonds to all your associations.

INHERITANCE is covered in the second half of the course. Inheritance between classes is shown with an open triangle. The same symbol is used for superclasses and interfaces, with the tag <> or < included with the classname......

Fundamentals of UML and Class Diagrams and Sequence and Activity Diagrams