Rekayasa Perangkat Lunak Analisa (Prosedural)
Perspec8ve • • • •
external perspec8ve interac8on perspec8ve structural perspec8ve behavioral perspec8ve
Analysis Model • Representasi technical pertama dari sebuah sistem. • Kombinasi text dan diagram untuk merepresentasikan soAware requirements (data, func8on, dan behavior) – in an understandable way.
• Mempermudah proses menemukan ke8dak konsistenan dan kelalaian dalam requirement
Analysis Model Guidelines • Produk analisis harus bisa dimaintenance, terutama SRS. • Masalah ukuran harus ditangani dengan menggunakan metode par8si yang efek8f . • Gunakan grafik jika diperlukan. • Bedakan antara per8mbangan logical (essen8al) dan physical (implementa8on). • Temukan sesuatu untuk membantu dalam par8si requirement dan dokumentasinya. • Menemukan cara untuk melacak dan mengevaluasi user interface. • Merancang tools yang menggambarkan logika dan kebijakan yang lebih baik daripada narasi.
Analysis Model Objec8ves • Menjelaskan kebutuhan customer • Menjadi dasar untuk proses soAware design. • Menentukan/merencanakan sekumpulan requirement yang bisa divalidasi setelah soAware selesai dibangun.
Requirement Modelling •
Scenario-‐based models
– point of view of various system “actors”
•
Data models
– The informa8on domain for the problem
•
Class-‐oriented models
•
Flow-‐oriented models
– represent object-‐oriented classes and the manner in which classes collaborate to achieve system requirements
– represent the func8onal elements of the system and how they transform data as it moves through the system
•
Behavioral models
– depict how the soAware behaves as a consequence of external “events”
Analysis Modelling Approaches • structured analysis
– Data and processes as separate en88es – Data objects are modeled in a way that defines their aTributes and rela8onships. – Processes are modeled in a manner that shows how they transform data as data objects flow through the system.
• object-‐oriented analysis
– Focuses on the defini8on of classes and the manner in which they collaborate with one another to effect customer requirements. UML and the Unified Process are predominantly object oriented.
Structured Analysis Model Elements • Data dic8onary
– contains the descrip8ons of all data objects consumed or produced by the soAware
• En8ty rela8onship diagram (ERD)
– depicts rela8onships between data objects
• Data flow diagram (DFD)
– provides an indica8on of how data are transformed as they move through the system; also depicts func8ons that transform the data flow (a func8on is represented in a DFD using a process specifica8on or PSPEC)
• State diagram (SD)
– indicates how the system behaves as a consequence of external events, states are used to represent behavior modes. Arcs are labeled with the events triggering the transi8ons from one state to another (control informa8on is contained in control specifica8on or CSPEC)
Data Modeling (ERD) • Elements:
– Data object -‐ any person, organiza8on, device, or soAware product that produces or consumes informa8on – ATributes -‐ name a data object instance, describe its characteris8cs, or make reference to another data object – Rela8onships -‐ indicate the manner in which data objects are connected to one another
• Cardinality and Modality (ERD)
– Cardinality -‐ in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object (1:1, 1:N, M:N) – Modality -‐ zero (0) for an op8onal object rela8onship and one (1) for a mandatory rela8onship
Crea8ng En8ty Rela8onship Diagrams • Customer asked to list "things" that applica8on addresses, these things evolve into input objects, output objects, and external en88es • Analyst and customer define connec8ons between the objects • One or more object-‐rela8onship pairs is created for each connec8on • The cardinality and modality are determined for an object-‐rela8onship pair • ATributes of each en8ty are defined • The en8ty diagram is reviewed and refined
Screnario Based Modelling • Create Preliminary Use-‐Case – list the func8ons or ac8vi8es performed by a specific actor – develops use cases for each of the func8ons noted
• Refine Preliminary Use-‐Case – alterna8ve interac8ons
• Wri8ng a Formal Use-‐Case
Safehome
Func8onal Modeling and Informa8on Flow (DFD) • Shows the rela8onships of external en88es, process or transforms, data items, and data stores • DFD's cannot show procedural detail (e.g., condi8onals or loops) only the flow of data through the soAware • Refinement from one DFD level to the next should follow approximately a 1:5 ra8o (this ra8o will reduce as the refinement proceeds) • To model real-‐8me systems, structured analysis nota8on must be available for 8me con8nuous data and event processing (e.g., Ward and Mellor or Hately and Pirbhai)
Crea8ng Data Flow Diagram • Level 0 data flow diagram should depict the system as a single bubble • Primary input and output should be carefully noted • Refinement should begin by consolida8ng candidate processes, data objects, and data stores to be represented at the next level • Label all arrows with meaningful names • Informa8on flow must be maintained from one level to level • Refine one bubble at a 8me • Write a PSPEC (a "mini-‐spec" wriTen using English or another natural language or a program design language) for each bubble in the final DFD
What do they look like? • As usual there are a number of “standards” for drawing DFDs • They share a set of common elements – Data Flow – with label to indicate what data is flowing – Processes – that handle a data – Data stores – within the system – External en8ty – outside sources of data
Example 1 – Gane and Sarson
Example 2 – DeMarco/Yourdon
Example 3 -‐ SSADM
Behavioral Modeling (STD) • State transi8on diagrams represent the system states and events that trigger state transi8ons STD's indicate ac8ons (e.g., process ac8va8on) taken as a consequence of a par8cular event • A state is any observable mode of behavior • Hatley and Pirbhai control flow diagrams (CFD) and UML sequence diagrams can also be used for behavioral modeling
Behavioral Modeling • Mendeskripsikan status sistem yang dapat muncul ke8ka perangkat lunak digunakan mendeskripsikan kelakuan sistem • Tools: – State Transi8on Diagram – Control Specifica8on
• Umumnya digunakan pada sistem waktu-‐ nyata
State Transi8on Diagram • Contoh STD untuk mesin otoma8s penjual minuman
Control Specifica8on • Fungsi C-‐SPEC sama dengan P-‐SPEC namun berisi deskripsi dari se8ap status yang dapat muncul pada sistem
Crea8ng Control Flow Diagrams • Begin by stripping all the data flow arrows form the DFD • Control items (dashed arrows) are added to the diagram • Add a window to the CSPEC (contains a SD that is a sequen8al specifica8on of the behavior) for each bubble in the final CFD
Safehome SoAware Control panel of SafeHome soAware System
SafeHome SoAware – Problem Defini8on
External & Internal En88es • • • • • • • • •
Home owner • Sub-‐systems Security System • Data storage Installa8on Telephone connec8on Audible Alarm Sensor System Control panel LCD display Func8on keys
Main Func8ons • • • • • •
System configura8on Sensor monitoring User interac8on Message display and status Password verifica8on System Ac8va8on/Deac8va8on
Func8on breakdown
Context-‐level Diagram
Data Flow Diagram (level-‐1)
DFD (level-‐2) : Monitor Sensor
Control Flow Diagram (level-‐1)
Process Ac8va8on Table
State Transi8on / Finite state Machine
Data Dic8onary Data Construct
Nota-on Meaning
= is composed of
• Sequence • Selec8on • Repe88on
+ and [ | ] either-‐or { } n n repe88on of ( ) op8onal data * … * delimits comments
Data dic8onary (example)
Referensi • Yani Widyani, Chris8ne Suryadi , 2008 , “IF2261 – Rekayasa Perangkat Lunak” , hTp://kur2003.if.itb.ac.id/kuliah.php? kode=IF2261
