OBJECT-ORIENTED Object Analysis And Design ANALYSIS • Earlier, we saw a number of different software lifecycle • The goal is to start from the requirements, and to come up Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department models. with a description of the software (classes with their attributes and methods) which can be implemented in a fairly • Similarly, there exists different ways to develop object straightforward way. oriented (OO) software. • Usually we talk about “analysis model” and “design model”. • We will start with a very basic OO waterfall model as given in the textbooks. That model is ok, if there is no (relational) • Analysis model is something which, in principle, describes the database and the software is not that big. system in OO terms, but we would not want to implement it as such, for reasons such as efficiency and maintainability. • Later, we will study why this is typically only good for small non-database software. • Design model is something we want to implement. • We will also study how large-scale database-driven OO software should be developed. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se Object Analysis OBJECT ANALYSIS • Goal: Start from the requirement specification and come up • Although there is some variance, most methods are based on Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department what is called OMT (Object Modeling Technique). with • I present a simplified technique, which follows the main ideas – A description of the classes (commonly a class diagram, to be of most of these methods. introduced later) • I will present the technique using an example, which I have – A description on how the use cases are to be executed using modified from ”Oliokirja” by Kai Koskimies. these classes (with some other UML diagrams such as • The example is a simplified version of the famous Finnish sequence diagrams, also to be introduced later). board game ”Afrikan tähti” (African Star). • Methods: • I will explain the various types of diagrams as they are – “Meditation” which more or less means “no methods”. needed. – Requirement specification text analysis. <- In these slides! – Analysis of all possible technical documentation of an old system or other existing systems. – Possibly separate analysis of the domain (e.g. banking). Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se Object Design - Architecture Object Design • This typically starts with something called “architectural • Once the architectural decisions have been made, the Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department design”, which in a way describes the basic solutions and or analysis model is developed into a model describing the models, which the design is going to follow. classes that we are actually going to implement. • Here, we identify different processes, which possibly run on • The UML diagram types are probably mostly the same as in different computers. analysis, but new classes, methods and attributes are introduced for the implementation. • There is a number of “design styles”, which may be applied. • The technology and the software development tools may probably have a major impact on the architectural solutions. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se 1
Example Board Game Object Analysis Goals/Phases Requirement Specification / 1 The game shall be implemented as a computer application with a graphical 1. Identify classes. Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department user interface. The game is played by two or more players. Each player has a playing piece, which all look different. The pieces are moved on the 2. Create a vocabulary, which is updated continuously. playing board. When the game starts, all pieces are in starting place and 3. Identify associations. each player recieves a sum of game money. The game has a set of places, on which the pieces can be positioned. The places are either 4. Identify responsibilities. ordinary places or special places. Some pairs of these places are 5. Identify operations (methods) connected by a connection. Graphically, the connections form paths on the board. There are flight connections for some pairs of places. 6. Identify attributes 7. Create inheritance structure The players take turns to play. The game includes a dice, which shows how many steps each playing piece is to be moved in each turn. With each 8. Check and clean-up step, the players’ piece is moved from one place to another place using a connection on condition that these places are connected. A player may use a flight connection by paying one unit game money, assuming he is at one end of the flight connection when his/her turn comes. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se Example Board Game Use Case ”Start” Requirement Specification / 2 Name: Start At the start of the game, each special place has a card face down. When a Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department player arrives to a special place, he/she may pay one unit game money to Version: 1.0 take the card (which can only be taken once). Alternatively, the player may Summary: The game is initialised stay on a special place, and instead of moving, throw the dice for trying to Frequency: Once per every game played take the card: dice values 4,5, and 6 mean the player gets the card. Usability Requirements: The card may be a bandit, meaning the player loses all money, a jewel with Actors: Players, the game application a value, meaning that the player receives money for that value, or a Preconditions:. treasure. The treasure may not be sold, but if another player arrives to a place which has a player with the treasure, the arriving player gets the Descriptions: The game application shows a dialogue, where all treasure. When a player with the treasure arrives to the starting place, that player’s names are typed in. The game application randomly chooses player wins the game and the game ends. the game pieces for the players and the order in which players take turns. The game starting position is initialised by putting the pieces in the start place and randomly choosing the cards for the special The game boards, places, pieces, labels, connections, etc. each have a graphical representation in the user interface, but that representation is not places. specified here. Postconditions: Exceptions: Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se Sequence Diagram for Sequence Diagrams for Use ”Start” Cases • Sequence Diagrams show interaction between actors. Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department • The use cases may be drawn into sequence diagrams, which show the interaction between users and the system. Application • The sequence diagrams are fairly self-evident at this point: we have User Choose start two actors (the official term is ”classifier role” for sequence diagrams) and the arrows show the communication. Ask player names • The arrows represent (asynchronous) message passing or Player names (synchronous) method calls. Show pieces • Based on the sequence diagrams, it is possible to identify a set of tasks, which the system is to perform. Show initialised board - Vertical lines stand for actors ( here ”User” and ”Application”) - Tim e runs dow n in the diagram - Arrow s show interaction/ operations Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se 2
Recommend
More recommend
