BACK IN ORDER !
UML passpaper question 2008
Case - loan process - request loan -> request form, check credit status, draw contract, set interest rate,
Problems - what are the classes ? These are the things which we will store info about in the database - contract, request form, customer, pricing, etc.
Architecture describes the organizational structure, relationships, reversable into components, interactions .....
What makes a good architecture ? 20 marks
Draw DFD, FEM, then now the owner wants to make the system available as a web service. what changes to the
design ? - Object orientation ?
Difficulties in the exam - draw boxes and arrows free hand no time for ruler at all.
BPI vs, BPA vs BPR - give examples
--------------------------------------------------------------------------------------------------------
Why UML
big projects
All the UML diagrams model requirements and design of the system but
each diagram looks at the problem in a different way -
functional, static or dynamic view.They provide a complete and overlapping picture of the objects being modeled.
They can assess the complexity of a system eg, activity diagram
A fundamental concept of the Unified Modeling Language (UML) is that you use different diagrams for different purposes. Class diagrams are used to model the static nature of your system, sequence diagrams are used to model sequential logic, and state machine diagrams are used to model the behavior of complex classes. This gives different perspectives which would have otherwise produced systems not meeting the requirements of stakeholders
Functional view - The Use case diagram and the Activity diagram model how the system is supposed to work
They define the functions that the system must provide.
Use case diagram - describes the features that users expect the system to provide
Activity diagram - describes processes, including sequential tasks, conditional logic and concurrency.
Static viewProvides a snapshot or blueprint of the elements of a system but does not tell how the elements will behave.
The resources of the system are defined.
eg Class diagram -
Dynamic view - Includes diagrams that reveal how objects interact with one another, in response to the environment.
eg. sequence and collaboration and state diagrams
STD - describe how and why an object changes over time.
USE CASEUse cases are features of the system
Use cases show a functional view
Associations _____ indicate which actors will access which features of the system
Dependency - describes the nature of the relationships between use cases.
Includes <<include>> A -------> B A use case will always need help or call use case B
Extends <<extend>> A <-------B A use case may need help from B
Generalization One use case or actor inherits all the properties of another use case / actor ( arrow with a triangle at the end)
CLASS DIAGRAM Class Diagrams show a logical view (static)
Like an ERD, shows cardinality (multiplicity), and attributes
Classes are depicted as boxes with three sections, the top one indicates the name of the class, the middle one lists the attributes of the class, and the third one lists the methods
associative class - like a relationship between example person rents dvd - rental is an associative class that removes the many to many relationship
between person and dvd. It will have attributes as date due. and date borrowed.
INheritance : Very often two or more classes will share the same attributes and/or the same methods.
.
DYNAMIC MODELS Dynamic model diagrams show how runtime objects act out a use case by sending messages to each other. There are two sorts of dynamic-model diagrams: Sequence Diagrams and Collaboration Diagrams.v
They describe how objects collaborate. (collaboration, sequence diagrams)
Collaboration diagram - show how the behavior of several objects collaborating together to fulfill a common purpose
show the
message flow between objects in an OO application and also imply the basic associations (relationships) between classes.
State, Sequence (time focus), Collaboration (space focus), Activity (work focus), diagrams are used to express the behaviour of a system
COLLABORATION DIAGRAMIn O-O systems functionality is produced by objects working together
•Each object provides only a small element of functionality
•Objects work together (collaborate) by passing
messages (labelled arrow) Purpose:
To deliver functionality to a use case
To deliver functionality to an operation
To show how messages are passed between objects
To model different scenarios
To identify the classes that participate in a use case (early stages of project)
A message is an operation call that an object makes on another object
SEQUENCE DIAGRAMA sequence diagram shows the interaction between objects during a certain period of time
Each sequence diagram shows only the interactions pertinent to a specific use case
Shows the same interaction as in collaboration diagrams but emphasise the order of the messages over time
![]()
![]()
Simple Restaurant Sequence Diagram
DIFFERENCES
The main difference between communication diagrams and sequence diagrams is that sequence diagrams are good at showing sequential logic but not that good at giving you a “big picture view” whereas communication diagrams are the exact opposite.
They Model the same aspects of the system
Can be converted into one another
Collaboration diagrams do not show information about timing constraints
Sequence diagrams do not show the links between objects
http://www.agilemodeling.com/artifacts/communicationDiagram.htm
Sequence diagrams model the sequential logic of a use case.
OO approach to system development - shows things like inheritance,
aggregation, encapsulation and association)same notation of diagrams eg. in sequence and collaboration diagrams - consistency of the UML.
UML notation can be useful during the requirements gathering stage. For instance, use case diagrams will show the users what they must do, as well as what the system will do for them.
Introducing the UML (Unified Modeling Language)
As the world becomes more complex, the computer-based systems that inhabit the world also must increase in complexity. They often involve multiple pieces of hardware and software, networked across great distances, linked to databases that contain mountains of information. If you want to make systems that deal with this, how do you get your hands around the complexity?
The key is to organize the design process in a way that clients, analysts, programmers and other involved in system development can understand and agree on. The UML provides the organization.
Consider this: Would you tell a building contractor that you want a 4 bedroom, 3 bath home, about 2000 square feet - Start building it! We'll hammer out the details as we go along? We all know this is ludicrous. But sadly, this method of development is all too common in the software industry. Just as you would work with an architect to design a blueprint that would diagram exactly how the house is to be built, you will work with us on an UML diagram that will document exactly how your custom software system will be built.
The UML was released in 1997 as a method to diagram software design. It was designed by a consortium of the best minds in object oriented analysis and design. It is by far the most exciting thing to happen to the software industry in recent years. Every other engineering discipline has a standard method of documentation. Electronic engineers have schematic diagrams, architects and mechanical engineers have blueprints and mechanical diagrams. The software industry now has UML.
Before we move on next lesson consider some of the benefits of UML:
| 1 | Your software system is professionally designed and documented before it is coded. You will know exactly what you are getting, in advance. |
| 2 | Since system design comes first, reusable code is easily spotted and coded with the highest efficiency. You will have lower development costs. |
| 3 | Logic 'holes' can be spotted in the design drawings. Your software will behave as you expect it to. There are fewer surprises. |
| 4 | The overall system design will dictate the way the software is developed. The right decisions are made before you are married to poorly written code. Again, your overall costs will be less. |
| 5 | UML lets us see the big picture. We can develop more memory and processor efficient systems. |
| 6 | When we come back to make modifications to your system, it is much easier to work on a system that has UML documentation. Much less 'relearning' takes place. Your system maintenance costs will be lower. |
| 7 | If you should find the need to work with another developer, the UML diagrams will allow them to get up to speed quickly in your custom system. Think of it as a schematic to a radio. How could a tech fix it without it? |
| 8 | If we need to communicate with outside contractors or even your own programmers, it is much more efficient. |
Using The Unified Modeling Language will result in lower overall costs, more reliable and efficient software, and a better relationship with all parties involved. Software documented with UML can be modified much more efficiently. Your software will have a future.
