Need as soon as
CP616 Semester 1, 2004 ITECH 7201 Software Engineering: Analysis & Design Week 4 Domain Model, Sequence Diagram, Interfaces 1 Commonwealth of Australia Copyright Act 1968 Notice for paragraph 135ZXA (a) of the Copyright Act 1968 Warning This Material has been reproduced and communicated to you by or on behalf of Federation University Australia under Part VB of the Copyright Act 1968 (the Act). The Material in this communication may be subject to copyright under the Act. Any further reproduction or communication of this material by you may be the subject of copyright protection under the Act. Do not remove this notice. 1 Do not forget the lecture test Worth 10% of the course assessment Conducted during 1 hour of the lecture Early intervention assessment task Designed to help people who aren’t quite getting the concepts as yet Sample Lecture Test is on Moodle Next Week – Week 5 2 FOST 2 After completing this week’s tasks you should be able to: Develop simple domain models in EA Explain how noun-extraction is used to identify potential objects Develop simple sequence diagrams in EA Explain the relationship between domain models, sequence diagrams and use cases Write applications involving interfaces List the differences between interfaces and abstract classes This week’s tasks 3 FOST 3 Last week we discussed the development of Use Cases These are textual documents describing the goal, the actors and various scenarios revolving around a single action For example, Borrow Book or Withdraw Cash Use cases can become very sophisticated and when used formally can act as the communication document between stakeholders in large software projects The use case we will be dealing with will be more informal because they deal with smaller applications Use Cases 4 FOST 4 While Use Cases provide detailed unambiguous descriptions of functional requirements However, they are not used as documents to assist with coding. We need to refine use case documentation before we can create actual objects. Two new diagrams that we will consider in this class are: Domain model diagrams Sequence diagrams Towards Objects 5 FOST 5 A domain model diagram looks a little bit like a class diagram However, they serve a different purpose Class diagrams are used to model actual software objects Domain models are used to model real world objects These are “potential” objects that help us think about the problem domain We call them conceptual classes Some of these conceptual classes will be discarded Some new classes might be identified at a later stage Domain model diagram 6 FOST What is the difference between a domain class diagram and a design class diagram? [Ref: stackoverflow] If your focus is on the diagram itself, there are two big differences between diagrams about domain model and diagrams about design model: (At least this is what the Larman book Applying UML and Patterns says) In UML diagrams which represent domain model, you cannot use arrows. All classes are interlinked with a line, which signifies "relation", and you should use text annotations over the lines to illustrate what relation it exactly is. While in design models, you have to use arrows, all types of arrows: association, inheritance... etc In design model you have to specify the type of properties and methods etc, while in domain model you only have to write them without anything additional(just like in real world). For example, value: int in design model will be written as value in domain model. Reference: Applying UML and Patterns 3rd Edition Chapter 9 and 16. Ref: http://stackoverflow.com/questions/21265491/what-is-the-difference-between-a-domain-class-diagram-and-a-design-class-diagram 6 Let’s look at the example for the ATM withdrawal use case that we looked at last week. We’ll work on the main scenario, but remember that alternative scenarios are also used to extract information. The main (success) scenario is shown on the next slide We will identify all of the noun’s (naming words) as a starting point for looking for objects This is known as noun extraction Noun extraction 7 FOST 7 The Customer approaches the Bank’s ATM The customer inserts his/her card The ATM requests the customer’s PIN The customer enters his/her PIN The ATM validates the customer’s details The ATM displays a list of actions The customer selects withdraw The ATM displays a request for the amount The customer enters the amount The ATM ascertains that the customer has sufficient funds in his/her account The ATM issues the money requested The ATM returns the customer’s card ATM main Scenario 8 FOST 8 Customer Bank ATM Card PIN Details Action Amount Funds Account Money Extracted nouns Not all of these nouns will be considered as objects. For example, Funds and Money are synonyms Details describe the customer and will probably become attributes of Customer The PIN is probably an attribute of Card We’ll change the name of action to Transaction – that’s what the customer is identifying Remember this is an initial exploration of the problem domain – don’t worry about leaving anything out at this stage – we can add it later 9 FOST 9 Customer Bank ATM Card Transaction Funds Account Extracted nouns We can start with these conceptual classes and use a domain model in Enterprise Architect. As well as the conceptual classes, we will also model the relationships between them. A Bank communicates with the ATM A Bank own an Account A Customer has a Card Etc. They are modelled on the domain model diagram on the next slide. 10 FOST 10 Domain Model Note – I made my own version of the domain model. However, as I watched Banas’s video (see reading list), mine gradually morphed to be very similar to his I couldn’t find a place for Funds and this class will probably become an attribute of one of the other classes 11 FOST 11 The previous slides “connects up” the various classes using associations. It’s not important to model every possible association – that would make the diagram messy and unreadable. We just want the most important ones. We have different types of association modelled Normal associations – eg between Customer and Transaction Dependencies – eg between Card and ATM Aggregation – eg between Account and Bank Associations 12 FOST 12 Notice that each association has a label which indicates what the relationship actually is This label should start with a verb because it’s connecting two nouns ATM verifies Card etc. The ends of the association lines are called roles We can add multiplicities to the roles There is a 1 to 1 relationship between Card and ATM This means that during any interaction there is exactly one Card and exactly one ATM The relationship between Bank and Account might be 1 to many with one Bank having many Accounts, but an Account belonging to one Bank only. Associations 13 FOST 13 It is often useful to think about the conceptual classes in terms of the role they play. Objects can be Boundary Dealing with the interface between the actor and the system Control Dealing with the overall control of the system Entity Ordinary things Types of object 14 FOST 14 15 Sample domain model for a health insurance plan. Source: https://en.wikipedia.org/wiki/Domain_model FOST 15 A sequence diagrams models how responsibilities are spread between objects It shows how messages are passed between objects and the order in which they are passed The sequence diagram is laid out as a two dimensional graphic. Objects/Classes are placed along the top The primary actor is represented as a stick figure and is usually the object furthest to the left because it is initiating the action Refer Udacity. (2015). UML behavioural diagrams: Sequence – Georgia Tech – Software development process Sequence Diagram 16 FOST 16 Sequence Diagram Deposit Money Example 17 Refer to a very similar sequence diagram at - https://books.google.com.au/books?id=M2kMaxEZgeMC&pg=PA204&dq=sequence+diagram+for+atm&hl=en&sa=X&ved=0CC4Q6AEwAGoVChMIq4eph63zyAIVwuamCh2ApQPY#v=onepage&q=sequence%20diagram%20for%20atm&f=false FOST Refer to a very similar sequence diagram at - https://books.google.com.au/books?id=M2kMaxEZgeMC&pg=PA204&dq=sequence+diagram+for+atm&hl=en&sa=X&ved=0CC4Q6AEwAGoVChMIq4eph63zyAIVwuamCh2ApQPY#v=onepage&q=sequence%20diagram%20for%20atm&f=false 17 The objects are set out along the top. The name of each object is given as The name of the object itself A colon ( : ) The name of the class In our example, we don’t know the names of the objects so we just use colon class. For example, :ATM Sequence Diagram Elements 18 FOST 18 EA allows for Entity, Boundary and Control objects to be modelled. We will see example of Control objects later in the course The ATM will be a boundary object because it forms the interface with the Customer It’s how the customer interacts with the system The Bank and Account will be entity objects The primary actor is modelled as a little stick figure on the far left The primary actor initiates the action Sequence Diagram Elements 19 FOST 19 The customer inserts the card The ATM has the responsibility of reading the card and then requesting the customer’s pin When the ATM has the pin it sends a message to the Bank to verify the details The Customer indicates they want to make a deposit The ATM sends a message to the Bank which in turn sends the message to Account The Account object looks after the balance and therefore has the responsibility of updating it Sequence Diagram Elements 20 FOST 20 It isn’t necessary to model every single piece of information in a sequence diagram Only the most important parts For example, not all return statements need to be modeled if they don’t add to the developer’s understanding of the sequence Sequence Diagram Elements 21 FOST 21 Java – Interfaces 22 22 We introduced abstract classes in week 3 We saw they are similar to ordinary (concrete) classes The main difference is they cannot be instantiated If you attempt to make an object of an abstract class (using ‘new’) a compiler error will occur However they, Belong to the class hierarchy Can contain attributes, methods (including abstract), constructors and other elements of classes Abstract classes revisited 23 FOST 23 An abstract class exists for inheritance purposes only: Their methods are available to all of their subclasses. This saves development time and helps prevent inconsistencies. If you want to modify a method you only need do so in one place. They define a relationship between their subclasses. This facilitates polymorphism which is an extremely powerful feature of OO. Abstract classes revisited 24 FOST 24 An abstract class suffers from the same limitations as concrete classes They can only directly inherit from one superclass One of their subclasses cannot inherit from another superclass Hence, because our Rectangle class inherits from Shape it cannot inherit from any other class. This is called single inheritance Abstract classes revisited 25 FOST 25 Consider our Shape hierarchy from last week (see next slide) Let’s assume we want to be able to draw Rectangle objects and Square objects but not (for some reason) Circle objects We could Add an abstract draw ( ) method to Shape and let its subclasses implement it appropriately. However, this means that Circle would have a draw ( ) method and we don’t want that Create another abstract class called Drawable that has an abstract method called draw ( ). However, Rectangle can’t inherit from both Shape and Drawable so this would not work Shape hierarchy 26 FOST 26 Shape 27 FOST 27 We can solve our problem through the use of an interface Interfaces are not the same as Graphical User Interfaces (GUIs) which will not be covered in this course An interface is a class-like structure which provides a “contract” for objects