IMSE 12 UML contd Objectory Use Cases and

IMSE 12 UML (contd) Objectory, Use Cases and CRC cards

Summary of last week l UML classes, with attributes and operations l UML relationships: - generalisation - aggregation and composition - association and roles l multiplicity, navigability l derived attributes, visibility (public, private, protected) l multiple and dynamic classification, discriminators, meaningful arrows, meaningful joined lines, {complete}, <dynamic>

What is a Modeling Language? l l a modeling language is the graphical notation used in developing a system a modeling language plus a process (the steps to take to develop the system) make up the method used to produce a system graphical notation method modeling process language steps to take to develop the system

Processes l a process is the steps to take to develop the system l e. g. the waterfall life cycle whose steps or stages are: - l requirements analysis specification design implementation testing operation and maintenance other processes exist, and others are being developed

The Rational Objectory Process l the Rational Objectory software development process (known as Objectory) is being developed by the 3 amigos l UML and Objectory fit very well together, but UML can be paired with another process to produce a high quality method more suitable for a particular system modeling language UML Objectory process

Outline of Objectory l l l it’s hard to talk about graphical notation in isolation, without some process in mind we’ll consider an overview of Objectory to help us with UML the 4 steps or phases in the Objectory process are: - inception - elaboration - construction - transition the phases are iterative and incremental, software developed and released in pieces not in one big bang the construction phase in particular is highly iterative

The Inception Phase l ranges from a simple chat to a full blown feasibility study l establish the business rationale for the project l decide on the scope and size of the project l consider costs and time scales l get commitment from the customer to go ahead l very short phase relative to the others

The Elaboration Phase l l l l collect more detailed requirements identify main risks to the project’s success, via use cases (see later) do high level analysis do high level design create a plan for construction elaboration takes about one fifth of the total project time completed when detailed time estimates are established

Use Cases l l l a use case is a scenario, something the user wants the system to do, e. g. 1) make some selected text bold 2) order some goods 3) add a new software engineer use cases can be large as in 2) or small as 1) very useful aid for understanding functional requirements important to identify all the use cases required in the system to be developed use case diagrams are part of UML

Example of a Use Case Diagram an actor i. e. a role that a user plays to carry out a use case actors need the use case to be available maintain company car details project leader a use case update supervisor’s software engineer

The Construction Phase l l by far the largest phase, with many iterations each iteration contains analysis, design, implementation, unit testing, integration, documentation, demo to user l each iteration builds production-quality software, tested and integrated l each iteration satisfies a subset of the requirements, i. e. some of the use cases l each iteration may be delivered to external, early users or may be a purely internal delivery l good use of iteration, forcing developers to get used to delivering finished code

The Transition Phase l takes place after all pieces of the iteratively-produced software integrated, and system testing is complete l consists of - beta testing and any ensuing bug fixing - performance tuning - user training l lasts between the beta release and the final release of the software

CRC Cards l l Class - Responsibility - Collaboration cards not part of UML but should be used with UML to produce high quality systems Cunningham and Beck 1989 good points: u they help you to think in an object-oriented way u they emphasise responsibilities u they uncover generalisation and aggregation u they don’t use complex notation

Example of a CRC Card class name Project Leader add new software engineer to supervise software engineer remove software engineer display software engineers’ names software engineer responsibilities, services provided by the class collaborators, other classes needed to work with

Using CRC Cards l set of index cards is created for each class identified l one card created for a particular scenario l cards shared around developers l scenarios are acted out l cards are modified where problems occur

Domain model l l the domain model starts to explain how the entities (e. g. project leader, software engineer, company car) fit together the domain model is the starting point for class and interaction diagrams which are the basis of the design of the system the entities are potential classes, the ways they fit together are potential relationships the domain model, the use cases and the CRC cards capture functional requirements, and would all be done at a high level in the elaboration phase more detail would be added in the construction phase, along with detailed design (e. g. class diagrams, interaction diagrams), implementation, testing, documentation and demos, all produced iteratively and incrementally