1. Introduction to Object Oriented Software Development

Transcription

1 1. Introduction to Object Oriented Software Development a) Object: A set of data together with some operations that can be performed on that data. Eg. Bank Account. Data can be account number, name of account holder etc. Operations can be Withdrawal, deposit etc. b) Model: Simplified analogy of a real entity. Paper model of a building shows its size related to other buildings. c) Object Oriented System: Collection of objects sending and receiving messages from one another. d) Predictive Approaches i. Waterfall SDLC (System Development Life Cycle): A tool for managing complex processes by breaking them down into a series of phases and activities. It outlines step by step activities for each phase of SDLC, the role that stakeholders play in each activity and the deliverables expected from each activity. In waterfall SDLC, each step is completed before moving on to the next. ii. Main Limitations to the predictive approach: It fails to take account of inevitable changes in the lifetime of the development process. These models separate data and the operations performed, and all the data and processing related to a single entity can be spread throughout the system, so changes require a lot of work. e) Adaptive Approach i. Iterative SDLC (System Development Life Cycle): With an iterative SDLC we build a small section of the system and then try it out. From the results of these tests, we may need to make changes. Once satisfied that everything is working well, we add one more functionality, and repeat the whole process. Each iteration improves or adds some functionality. Early iterations emphasize requirements as well as analysis and design; later iterations emphasize implementation and testing. ii. Iterative Plan: Describes what to do in the first elaboration iteration. Includes how long the iteration will be, who will participate, and what they will produce. iii. Object Oriented Systems Design: An example of adaptive approach 1. Class: Blueprint that define the variables (or attributes) and the methods common to all objects of the same kind. Eg. Your car is an instance of the class Cars. 2. Object: An instance of a class. Have State, Behaviour and Identity. Most important thing in Object Oriented Concept. 3. Method: Refers to a piece of code that is exclusively associated either with a class (class methods and static methods) or with an object (instance methods). A method usually has a set of input parameters, and possibly an output return value. 4. Encapsulation: Process of hiding all the details of an object that do not contribute to its essential characteristics. Only the interface of the object is externally visible. 5. Inheritance: Capability of a class to use the properties and methods of another class while adding tis own functionality. Eg. In generalisation, subclasses inherit properties and methods of the superclass. Inheritance enhance ability to reuse code, and makes designing a much simpler and cleaner process 6. Polymorphism: Capability of an action or method to do different things based on the object that its acting upon. Overloading, overriding and Dynamic method Binding are types of polymorphism. f) Unified Process (UP): The process is a published industry standard for software development process especially for object oriented systems. It has 4 phases, yet all the phases are subdivided into iterations. i. Inception: Establish the case for the viability of the proposed system ii. Elaboration: Project starts to take shape here, problem domain analysis is made, project gets its basic form. iii. Construction: Focus goes to the development of components and other features of the system being designed. Here the bulk of the coding takes place. iv. Transition: The product moves from the development to end user. Here training takes place for end users and maintainers, and beta testing of the system to validate against end user expectations.

2 g) Unified Modelling Language (UML): defines standardised models and notations for expressing different aspects of an OO design. i. Use cases: Describes event sequences for an actor to use the system. A narrative description of the process. ii. Domain Model: Visualization of concepts in the realworld domain, not a description of software objects. iii. Interaction Diagram: Flow of messages between software objects and also the invocation of method. iv. Design Class Diagram: Shows software classes, not real world concepts. It has methods and attributes of classes. h) Analysis & Design: Analysis is what needs to be provided and design is how it will be provided. i) Object Oriented Analysis (OOA): Process of defining the problem in terms of objects: real world objects with which the system must interact, and candidate software objects used to explore various solution alternatives. j) Object Oriented Design (OOD): Process of defining the components, interfaces, objects, classes, attributes, and operations that will satisfy the requirements. You typically start with the candidate objects defined during analysis, but add much more rigor to their definitions. Then you add or change objects as needed to refine a solution. In large systems, design usually occurs at two scales: i. Architectural design: Defining the components from which the system is composed; and ii. Component design: Defining the classes and interfaces within a component. k) Importance of Design: Badly designed tools or user interfaces require effort to use and consequently one frequently makes mistakes or feels frustrated. The external aspect is the user interface. The internals are concerned with reliability, ability to change, resilience to new technology. Always remember that users of a system are people. A Good Design: i. Requires an understanding of the underlying basic principles and trade offs. ii. Requires experience. iii. Is not about right or wrong, but about being better in certain circumstances than others. l) Inception Phase: Where a project begins in UP. Primary goal is to check viability of the proposed system. Starts with an idea by someone. Then others with authority, finance, knowledge or skills need to be incorporated to form a vision of the project. Since this is iterative process, we expect many versions of the same things. Vital part of the vision is the Scope. Scope has to be smallest possible yet still having the core needs as bigger scopes tend to fail more often. As far as the inception phase of the project is concerned, what we want is an initial list of the names of the use cases. i. Pareto s Principle (80/20 Rule): This rule states that 80% of the value of a group of items is generally concentrated in 20% of the items. ii. Scope of a System: The sum of its parts. iii. Functional Requirements: Parts of the system that provide functionality, liking accepting a customer order, they are best described with Use Cases. (Others are what we call nonfunctional requirements). iv. Use Case: Description of the interaction between the user and the system, doesn t tell us anything about how the system works, written in simple everyday language, can be a simple, casual narrative describing how a user s goal is satisfied. Borrow a video use case simple story The customer takes the videos they have selected and goes to the checkout counter. There the clerk confirms their membership and checks for any overdue videos. The total cost is calculated; the customer pays, and leaves with their videos.

3 m) Inception Phase Artifacts: Various models, designs, documents, reports, spreadsheets, manuals and programming code that are produced during the development of a system. A methodology usually gives guidelines on which artifacts need to be produced, when they are produced in the development life cycle, the format (drawing, document, spreadsheet, etc.), and possibly who in the team should produce them. i. Inception Phase Artifacts: Vision & Business Case, Use Case Model, Supplementary Specification, Glossary, Risk List & Risk Management Plan, Prototypes & Proof of Concepts, Iteration Plan, Phase Plan & Software Development Plan, Development Case. 2. Requirement & Use Cases a) Requirements: Tells what the system will do, rather than how it will do it. b) Requirement Analysis: before we do anything at all, we have to ask ourselves what we want the system to do. To answer this question, it is necessary to consider: i. business needs ii. available resources iii. possible technologies iv. social and legal implications c) Writing the requirements involves: i. Defining the purpose of the system, prioritizing its functionality, and specifying its context (i.e. who are its users and what systems does it interact with?). ii. Identifying external interfaces, both human and system to system. The technology of an existing system with which the system must interface can constrain the requirements and design. iii. Identifying major functionality that must be provided by the system and describing it. iv. Documenting assumptions upon which the requirements are based. If the assumptions change, then so might the requirements. v. Communicating with users, clients, business analysts and developers so that the system that is developed meets the clients expectations. d) Some reasons an organization might start a new system development project: i. new business requirements, ii. replacing an old system, iii. the merging of two existing systems due to acquisition and merger, etc. e) Levels and Types of Requirements: i. Business requirements these define the high level processes that occur in an organization. For example, for a Banking system, what is the purpose of developing the new banking system? Is it going to replace an old system or is it going to be used in a new line of business, etc.? ii. System requirements what the computer system must do for its users. These are the functional requirements of the system. iii. Internal requirements relating to technology, personnel, hardware platform requirements, etc. These are the non functional requirements. f) Challenges of Writing Requirements: i. Problem Domain Complexity: The biggest challenge is finding out about the problem domain (the environment in which the system will operate, e.g. our video shop). ii. Person to Person Communication: For successful requirements analysis, groups involved need to convey information to one another effectively. iii. Constant Change: Changing requirements are an inevitable aspect of the software development life cycle. iv. Writing Requirements in UP: Key requirement artifacts; Use case Model and Supplementary Specifications.

4 g) Actors: Actors are entities outside of the system that will interact with the system. The term for Users in UML. Three kinds of Roles for Actors: i. Primary: A person in this role directly uses the system to enter, view process or extract information. ii. Secondary: A person in this role does not directly use the system, but uses or generates data for the system. iii. External: Any system that receives or generates data for the system. h) Writing Use Cases: i. Four Step Procedure to define use cases: 1. Define the right system boundary 2. Identify the primary actors 3. Identify the actors goals 4. Define and name the use cases. ii. Three types of format for writing use cases. 1. Brief use case it has one paragraph summary and normally used for main success scenario. 2. Casual use case it is an informal paragraph which has multiple paragraphs that cover various scenarios. 3. Fully dressed the most comprehensive that shows all the steps and variations. It has supporting sections, such as preconditions and success guarantees. However, detail discussion about fully dressed use case is beyond the syllabus. i) Use Case Diagrams: It provides a static view of a system to allow us to have an overview of the system and the relationship between the use cases as well as the actors of the system. j) Activity Diagram: Activity diagrams are very similar to FlowChart diagrams and they describe how things flow and connect to next actions. k) Potential Problems with use Cases: i. The system boundary is undefined or inconstant. ii. The use cases are written from the system s point of view. iii. The actor names are inconsistent. iv. There are too many use cases. v. The actor to use case relationships resemble a spider s web. vi. The use case specifications are too long. vii. The use case specifications are confusing. viii. The use case doesn t correctly describe functional entitlement. ix. The customer doesn t understand the use cases. x. The use cases are never finished. Activity Diagram l) How to Avoid Potential Problems: i. Explicitly define the system s boundary. This makes clear what is inside the system and what is outside the system. ii. Make use of a standardized template for documenting your use case specifications. iii. When writing use cases, focus on the goals of the actors. iv. Don t make use case specification synonymous with user interface design. m) Possibilities of Packaging the Use Case: i. By functional areas. For example, put everything to do with money in one package etc ii. By actor. For example, put all the cashier s use cases in one package. iii. By style of use case. For example, put all the simple setup/maintenance style use cases in one package. iv. By importance or iteration. For example, all the use cases that are going to be built first in one package. v. By physical implementation. For example, all the use cases that are delivered via the Web

5 3. Object Oriented Modelling a) Outcome of the Inception Phase should include: i. Vision document: a general vision of the project s requirements, key features, and main constraints ii. Initial use case model (10 20% complete) iii. initial project glossary iv. Initial business case, which includes business context, success criteria (revenue projection, market recognition, and so on), and financial forecast v. Initial risk assessment vi. Project plan showing phases and iterations vii. Business model, if necessary viii. One or several simple prototypes. b) Evaluation Criteria for the Inception Phase: i. Stakeholders agree on scope definition and cost/schedule estimates ii. Requirements understanding as presented in the primary use cases iii. Credibility of the cost/schedule estimates, priorities, risks and development process iv. Depth and breadth of any architectural prototype that was developed v. Actual expenditures versus planned expenditures. c) Elaboration Phase: In the elaboration phase, an executable architecture prototype is built in one or more iterations, depending on the scope, size, risk and novelty of the project. Most Critical of the four phases. i. Outcome of the Elaboration Phase: 1. Use case model (at least 80% complete): all use cases and actors have been identified, and most use case descriptions have been developed 2. Supplementary requirements: these capture the non functional requirements and any requirements that are not associated with a specific use case 3. System Sequence Diagrams that describe the events and their order: these are generated by the actors and the system or inter system events 4. Domain model: a visualization of things in the domain of interest 5. Design model (partially complete): a set of diagrams that describes the logical design of the system 6. Software architecture document: this summarizes the key architectural issues and their resolution in the design 7. Data model (partially complete): this includes the database schema and the mapping strategies between object and non object representations 8. Test model (partially complete): this describes what will be tested 9. Executable architectural prototype 10. Revised risk list and a revised business case 11. Development plan for the overall project, including the coarse grained project plan, showing iterations and evaluation criteria for each iteration 12. Updated development case specifying the process to be used 13. Preliminary user manual (optional). d) Hierarchy of Models in UP: i. Conceptual Model End user point of view of how things would work nothing of how the processing happens ii. Logical Model How the system should be done Logically how things would happen Independent iii. Physical Model Cannot be changed from one machine to another. The final design model, showing how things will be done or built and depicting all platform details, data storage and other implementation details.

6 e) System Sequence Diagrams (SSD): illustrate events and operations sequentially, starting with the external actor s input to the system. f) Domain Model: A representation of things in the real world, simplified version of Business Model. In a domain model, we have three types of information: i. Domain object (or conceptual class) which identifies a business entity or concept, e.g. shop, video CD, member, etc. ii. Associations between domain objects which define relevant relationships, those that capture business information that needs to be preserved, and their multiplicity, e.g. a shop has many video CDs, a member borrows many video CDs. iii. Domain object attributes which are logical data values of an object, e.g. each member may have a member s number which is an attribute of the object member. g) Conceptual Classes: Represents something physical or conceptual in a business. Three kinds are: i. Concrete objects: are tangible, i.e. has a physical presence. Eg Video CD, Banana etc ii. Conceptual objects: are intangible and often far more difficult to understand. Eg. School, Video Title etc. iii. Event and state objects are highly abstract in nature. They are related in that typically when an event of any significance occurs, some or more objects will switch to a different state. An example of an event and state object in the video shop is borrow video. We can see that borrow video events will typically change the status (e.g. borrow video list) of the object. h) Specification Conceptual Classes: When it s appropriate to use: i. There is a need to describe about an item or service, independent of the current existence of these items or services ii. Deleting instances of things that they describe (for Example: Item) results in a loss of information that need to be maintained iii. It reduces duplicated information i) Associations: An object oriented term for relationship. In UML, an association is a relationship expressing the interaction between instances of two conceptual classes, represented by the verb that describes what they do to each other, and/or by the nouns for the roles that each plays in the life of the other. i. Multiplicity: The number of instances of each class that can participate in an occurrence of the association. j) Attributes: are the pieces of data we use to identify or describe things. Eg. a person has a name, date of birth and eye colour. i. Criteria to eliminate unnecessary and incorrect attributes: 1. If the independent existence of an entity is important, rather than just its value, then it is a separate class. 2. An entity that has features of its own within the given application is a separate class. 3. If the value of an attribute depends on a particular context then consider restating the attribute as a qualifier. 4. A name is a class attribute when it does not depend on context, especially when it need not be unique. 5. Do not list object identifiers that are used purely for unambiguously referencing an object. 6. If an attribute describes the internal state of a class that is invisible outside the class then eliminate it from the analysis. 7. Omit minor attributes that are unlikely to affect most operations.

7 4. More Use Cases a) Three Kinds of Relationships Between Use Cases: i. Include: Typically where a set of use cases each includes some common functionality that is expressed in one shared sub use case. ii. Extend: Where the functionality of a use case is extended by referencing other use cases; and iii. Generalize: Where several use cases share something similar. b) State Diagram: A state diagram shows the life cycle of an object: what events it experiences, its transitions, and the states it is in between these events. On these diagrams we then write the use case names, which in doing so, we often discover missing use cases. c) CRUD (Create + Read + Update + Delete): Second technique that helps us to find missing use cases. We need to examine every class in the conceptual class diagram to ensure that either we have all of these operations, or we can decide not to include them. State Diagram showing Super State d) Business Rules: Probably the most basic part of requirements analysis and should be done concurrently with the use case modeling. Besides their role in the use cases, business rules are also linked to other artifacts in the software development process. e) Robustness Diagram: i. Robustness analysis (Use Case Analysis): Involves analyzing the narrative text of use cases and identifying a first guess set of objects that will participate in each use case. This technique can help us to produce a preliminary design. Robustness diagrams help us cross the divide from analysis to design. The objects on robustness diagrams can be classified into three types, namely: 1. Boundary Objects: Represent all connections between the internal objects of the system and the outside world. Eg. User Interface like Window or Dialoguebox, Barcode Readers etc 2. Entity Objects: Objects that represent data that have to be remembered by the system, either on a more permanent basis beyond the execution of the use case (such data might be stored in a database table), or for the execution of a use case. 3. Controller Objects: Represent anything else you find you need to make the whole diagram make sense. Eg. business rules or processes that are captured by a use case

8 5. Dynamic Modelling a) Design Model: In the design Model, we will produce two diagrams: i. Design class diagram: Defining classes and the relationships between them. It represents the static aspect of the design model. ii. Interaction diagrams: which define class/object interactions. They represent the dynamic aspect of the design model. There are two types of interaction diagrams, namely the sequence diagrams and the collaboration diagrams. b) Class: A collection of objects with common structures, behaviors, relationships and common semantics. i. Identifying Classes: 1. Use the requirements model/use cases/domain model, and find the nouns. These will most likely be classes. 2. Use the technique of robustness analysis to identify additional classes. 3. Suggest responsibilities. 4. Identify attributes. 5. Identify operations. ii. In UML, a class is drawn as a rectangle with three compartments: one for the class name and any modifiers, one for attributes and one for operations. iii. Attribute: The structure of a class is represented by its attributes. Has a name and type separated by a colon : iv. Operations: Behavior of a class/object that acts upon the attributes in the class/object. Can have input (in), output (out) and input/output (inout) arguments. All arguments have a name and type (separated by a colon) and are prefixed by the term describing what type of argument they are. v. Three types of operations existing in a Class Diagram: 1. Constructor operation is used to create new objects for a class by giving initial values for the attributes. The name of the constructor operation is same with the name of the class. 2. Query operation is used to access only the object s state and this operation does not change the state of a object (e.g. getname, getpay, RetrieveID, checkpassword, etc). 3. Update operation is used to update or change the value of attribute(s) of a object. This update operation will change the state of the object (e.g. setname, updateage, etc). vi. To specify an object, we also use a rectangle, but the name is underlined. c) Interaction Diagram: Used to define the class/object interactions within the system. They show the dynamic aspect of the system, e.g. the flow of messages. Two types are: i. Collaboration diagrams: Depict an interaction among elements of a system and their relationships organized in time and space. Its elements are: 1. Classes, denoted as class rectangles, to represent the objects involved in the interaction. 2. Association roles, which represent roles that links may play within the interaction. 3. Messages, denoted as labeled arrows, to represent messages sent between objects. The

9 arrow points from the object that sends the message to the receiving object. Optionally, parameters are passed as part of the message; and also optionally, some information, or another object is passed back. ii. Sequence diagrams: Sequence diagrams depict an interaction among elements of a system organized in time sequence. Its elements are: 1. Class roles, denoted as class rectangles, represent roles that objects may play within the interaction. 2. Lifelines, denoted as dashed lines, represent the existence of an object over a period of time. 3. Activations, denoted as thin rectangles, represent the time during which an object is performing an operation. 4. Messages, denoted as labeled horizontal arrows between lifelines, represent communication between objects. d) Design Class Diagram: Describes classes that will exist in software. i. Visibility: The visibility of an attribute or method within a class determines what other objects can access it. It is a desirable design practice to keep attributes of your class private, providing access to them through accessor methods. The options are: 1. Public visibility denoted by + in UML (or by an icon in the tool) means that objects of any class can use the attribute or operation. 2. Protected visibility denoted by # in UML (or by an icon in the tool) means that only objects of that class or its subclasses can use the attribute or operation. 3. Private visibility denoted by in UML (or by an icon in the tool) means that objects of only that class can use the attribute or operation. ii. Association: An association is a connection between classes and is shown as a line connecting the related classes. If there are no arrows on the line, it is assumed to be bidirectional. iii. Composition ( Uses a Relationship): (a.k.a. composite aggregation) is a stronger form of aggregation where the part is created and destroyed with the whole. Eg. A rectangle is made up of several points. If the rectangle is destroyed, so are the points. (Filled Diamond) iv. Aggregation ( Has a Relationship): In an aggregation relationship, the part may be independent of the whole but the whole requires the part. Eg. An order is made up of several products, but a product continues to exist even if the order is destroyed. (Unfilled Diamond) v. Differences between Conceptual and Design Class Diagrams Concept Conceptual Design Classes Relationships Inheritance Cardinalities Attributes Methods Yes Represents Real World Entities Has a Navigation is irrelevant Is a Relationship Yes Show key ones Types are optional Usually very few Yes Represents Software Classes Adds direction to the Has a relationships. Pass Messages to Classes Inherit code Yes Add more Attributes Add Types Add many more, with full parameters

10 e) Inheritance ( Is a Relationship): Capability of a class to use the properties and methods of another class while adding its own functionality. (Filled Arrow) i. Polymorphism: Capability of an action or method to do different things based on the object that it is acting upon. Eg. While giving the command to print a file, the owner object does not need to know what type of document it is before giving the command. It means that the exact code of the method will change according to the class of the object that receives the message. ii. Concrete & Abstract Classes: Are Specified in either Italics or the word concrete or abstract are added within curly brackets. 1. Abstract Class: A class that never has any objects (that we can physically touch). Eg. Groupings like Fruits etc. Abstract classes should not inherit from concrete classes 2. Concrete Class: A class that has objects (that we can physically touch). Eg. Apple. Concrete classes should always be the leaves f) Design Principles: i. Coupling: Strength of association between two classes. Strong coupling is bad. Four basic forms of coupling: 1. Identity coupling: measures the level of connectivity of a design. This is shown as an association on a class diagram. A one way association is less coupled than a two way association. 2. Representational coupling: Measure of how one object accesses the data of another object. 3. Subclass coupling: When a client class directly references a subclass rather than its superclass. This is to be avoided wherever possible. 4. Inheritance coupling: A subclass is related to its superclass by inheritance coupling. ii. Cohesion: Measure of how focused the functionality of a class is. High cohesion if class represents only one idea. Eg. The class VideoSpecification defines a particular title of a movie. It tells us something about that movie (its name, the actors, year it was made, ratings, and so on). The class Video is all about one particular tape of a video specification. Thus Video and VideoSpecification are separate classes. If they were merged into one, the resulting class would not have high cohesion.