Análise de Sistemas de Informação (ASI)

Transcrição

1 Análise de Sistemas de Informação (ASI) Ano LecFvo 2012/2013 * 1º Semestre Mestrado em Engenharia InformáFca Aula 10 1

2 Previously... Content adapted from Systems Analysis and Design with UML, 4th EdiFon InternaFonal Student Version Alan Dennis, Barbara Haley Wixom and David Tegarden, Wiley,

3 The Analysis Phase: Business Process and FuncFonal Modeling Business Process Iden3fica3on with Use Cases and Use- Case Diagrams Business Process Modeling with Ac3vity Diagrams Business Process Documenta3on with Use Cases and Use- Case Descrip3ons Verifying and Valida3ng the Business Processes and Func3onal Models Content adapted from Systems Analysis and Design with UML, 4th EdiFon InternaFonal Student Version Alan Dennis, Barbara Haley Wixom and David Tegarden, 3 Wiley, 2012

4 Business Process DocumentaFon with Use Cases and Use- Case DescripFons Use- case diagrams provide a bird s eye view of the basic funcfonality of the business processes contained in the evolving system Ac3vity diagrams open up the black box of each business process a providing a more detailed graphical view of the underlying acfvifes that support each business process Use- case descrip3ons provide a means to more fully document the different aspects of each individual use case They are use the informafon on: the idenffied requirements the use- case diagrams and the acfvity diagrams that are sketched 4

5 Example 5

6 Verifying & ValidaFng a Use- Case Use- cases must be verified and validated before beginning structural and behavioral modeling: we need to ensure that funcfonal models faithfully represent the business processes under considerafon The use- case diagrams, the acfvity diagrams and the use- case descripfons must describe the same funcfonal requirements UFlize a walkthrough: Perform a peer review of the models and diagrams created so far Performed by individuals from the development team and the client (very interacfve) Facilitator: schedule and set up the meefng Presenter: the one who is responsible for the specific representafon being reviewed Recorder (scribe) to take notes and especially to document errors 6

7 The Analysis Phase: Structural Modeling Class- Responsibility- Collabora3on (CRC) Cards Class Diagrams Object Diagrams Content adapted from Systems Analysis and Design with UML, 4th EdiFon InternaFonal Student Version Alan Dennis, Barbara Haley Wixom and David Tegarden, 7 Wiley, 2012

8 IntroducFon FuncFonal models (Use cases, Use- case diagrams, AcFvity diagrams and Use- Case descripfons) represent system behavior A structural model describes the structure of the objects that support the business processes in an organizafon, and that are used and created by a business system. They represent system objects and their relafonships: People, Places, Things, about which informafon is captured During Analysis, a conceptual model is drawn (it shows the logical organizafon of the objects without indicafng how the objects are stored, created and manipulated; the model is implementafon and technical- details free) Later, during Design, analysts evolve the conceptual model into a design model; they use the arffacts that are produced during Analysis 8

9 Structural Models Create a common vocabulary for analysts & users Allows effecfve communicafon They do not represent somware components or classes in an OO programming language, even though they contain analysis classes, akributes, opera3ons and rela3onships among analysis classes The refinement of these inifal classes intro programming- level objects comes later They should represent the responsibilifes of each class and the collaborafons among the classes Typically, they are depicted using: CRC cards Class diagrams Object diagrams 9

10 Structural Models Main goal: to discover the key data contained in the problem domain and to build a structural model of the objects Structural Modeling Problem Domain SoluFon Domain 10

11 Classes, Anributes, & OperaFons Classes (abstract vs. concrete) General templates for instances of people, places, or things All objects of a class are idenfcal in structure and behavior, but contain different data in their: Anributes ProperFes that describe the state of an instance of a class (an object) Contain informafon that the system should store OperaFons AcFons or funcfons that a class can perform Evolve later to methods 11

12 RelaFonships Describe how classes relate to one another Three basic types in UML GeneralizaFon Enables inheritance of anributes and operafons Represents relafonships that are a- kind- of AggregaFon Relates parts to wholes Represents relafonships that are a- part- of AssociaFon Miscellaneous relafonships between classes Usually a weaker form of aggregafon 12

13 Object IdenFficaFon Textual analysis of use- case descripfons to idenffy possible classes, anributes, operafons and relafonships (from the Make Old PaFent Appt, we can idenffy potenfal objects: old pafent, doctor, appointment, pafent, office, recepfonist, name, address, pafent informafon, payment, date and Fme) Common nouns suggest classes (a proper noun implies an instance of a class) An adjecfve implies an anribute of an object A doing verbs suggest operafons pafent contacts office, makes a new appointment, A having verb implies an aggregafon or associafon relafonship Creates a rough first cut to provide an object list 13

14 Object IdenFficaFon Brainstorming people offering ideas IniFal list of classes (objects) is developed Anributes, operafons and relafonships to other classes can be assigned in a second round Common Object Lists Physical things Incidents Roles InteracFons PaKerns Useful groupings of collaborafng classes that provide solufons to common problems (are reusable) Developed panerns provide a starfng point for work in similar domains 14

15 Class- Responsibility- CollaboraFon Cards Index cards used to document the responsibilifes and collaborafons of a class Responsibili3es Knowing what a class must know manifested as anributes Doing what a class must do manifested later as operafons Collabora3on Objects working together to service a request: Requestor (client) Responder (server) Bound by a contract (e.g., a pafent makes an appointment with a doctor) They are combined with anthropomorphism pretending that classes have human characterisfcs. Regarding a class, ask: Who or what are you? What do you know? What can you do? 15

16 Front- Side of a CRC Card 16

17 Back- Side of a CRC Card 17

18 CRC Cards & Role- Playing Another exercise to help discover addifonal objects, anributes, relafonships & operafons Team members perform roles associated with the actors and objects previously idenffied UFlize ac3vity diagrams to run through the steps in a scenario (a single, unique execufon path) IdenFfy an important use- case (e.g., Make Old PaFent Appt) Assign roles based on actors and objects (we need an Old PaFent and a Doctor) Team members perform each step in the scenario (if a team member is assigned the role of Doctor, he/she should be able of performing every step in the scenario associated with the Doctor) Discover and fix problems unfl a successful conclusion is reached Repeat for remaining use- cases 18

19 Summary SDLC, The analysis phase: - Structural Modeling: what is it and why is it needed using CRC cards to model the structure of the objects that support business processes 19